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Version 6.3 Changes 

Version 6.3 of the MODCAL ERS contains a number of changes to content 
and formatting. A summary of the differences is given below: 

- Corrected Module Qualification syntax. 

- Marked several features as NOT IMPLEMENTED . 

- Corrected assignment mechanism for Procedural variables. 

- Extended the definition of Sizeof. 

- Made a separate section for READONLY. 

- Added a section for ANYVAR. 

- Added Object /Off set model diagram. 

- Added an example of XCall. 

- Updated predefined assembly instruction for Vision foundation 
module. 

- Added $PRIVATE_PROCE OFF$ requirement to OPTION Inline. 

- Added OPTION Uncheckable_ANYVAR. 

- Modified OPTION Extensible_Gateway to work on the 3000. 

- Added tables of permitted Definition Option / Directive 
combinations. 

- Added $SET, $IF, $ELSE, and $ENDIF compiler options. 

- Added several missing Pascal/3000 compiler options. 

- Expanded the descriptions of $PUSH$ and $P0P$. 

- Added new reserved word ANYVAR 

- Changes are shown in a BOLDER type face. 

- Features that will not be implemented soon are shown in a smaller type face. 

Version 6.1 Changes 

Version 6.1 of the MODCAL ERS contains the XCall Mechanism. 

Version 6.0 Changes 

Version 6.0 of the MODCAL ERS contains the changes made that were 
reflected in the Delta ERS (May 19). A summary of the differences is given 
below: 



- Try recover statememt and Escape function are not permitted in code 
that will execute on the ICS. 

- Variable type coercion is permitted only for actual parameters 

- The grammar for object /off sets was changed. 

- Predefined procedure BuildPointer was added 

- Predefined function CurventObject was added. 

- Predefined function GetObjeotSize was added. 

- Predefined procedure TestDown was changed to a Boolean function. 

- Procedure definition options (Gateway, Extensible_Gateway, Inline, 
Def ault_Parms , Interrupt_Parms and Unresolved) were added. 

- Predefined functions HaveExtension and HaveOptVarParm were added. 

- The size of crunched structures is temporarily limited to 20U8 words 
(32 k-bits) or less. 

Vers ion 5.0 Changes 

Version 5.0 of the MODCAL ERS contains many significant changes and 
additions over versions 3.0 and k.O (both of these versions were very 
similar in -content). The differences in the order they appear in version 
5 . are : 

- The syntax notation was changed to use regular expressions. 

- Definition module feature was added. 

- Export qualifiers were added. 

- Escape and EsoapeCode definitions were refined. 

- Type coercion definition was rewritten. 

- Variable type coercion was added. 

- HeOra function was added. 

- Procedural type and Call definitions were refined. 

- Functional type and FCall definitions were added. 

- Sizeof and Addr functions were added. 

- Schema array feature definitions were refined. 

- Withobject syntax was extended. 



Predefined object procedure definitions were refined. 

Stack function was added. 

Predefined pointer arithmetic procedure/function definitions were 
refined. 

OffsetPart and ObjeotPart functions were added. 

Crunch packing definition was rewritten. 

Move_R_to_L and MoVe_L_to_R procedures were added. 

Multiple heaps definition was removed. 

Portability foundation definitions were refined. 

Assembly language predefined procedures /functions were added. 

Definition option explanations were added. 

Unresolved definition option was added. 

Inline and Split directive stuff was deleted. 

Directive explanations were refined. 

Compiler option explanations were added. 

Data type / data representation matrix was added. 

Data representation explanations were added. 

Type compatibility definitions were refined. 

Reserved word lists were added. 



Introduction 

The original Pascal programming language is described in the 
Pascal User Manual and Report by Jensen and Wirth. Three of the principal 
design goals of the Pascal language were: 

1) The language should be suitable for teaching the concepts of struc- 
tured programming, 

2) It should be possible to construct simple, efficient and portable 
compilers for the language, and, 

3) The language should be type-safe and allow compile-time type 
checking. 

These design goals were essentially met; however they resulted in 
Pascal being based on a very simple, restricted machine model. The 
Pascal virtual machine consists of a program code area, a stack area for 
local and global variables, and a heap area for dynamically allocated 
data. This machine model does not give the programmer access to the 
full power of the underlying computer architecture. For example, within 
Pascal there is no way of storing and accessing variables in HP3000 
extra data segments or Vision objects. 

This is not surprising, since Pascal was never intended to be a 
systems programming language. It is, however, quite feasible to use 
Pascal as a basis for a systems programming language. Mesa and Ada are two 
prime examples of Pascal -based systems programming languages. The main 
sacrifice in converting Pascal to systems programming use is the loss of 
full type -safety. 

This document describes a set of extensions to HP Standard Pascal that 
enables it to be useful for systems programming work such as operating 
systems, data bases, and data communications. This extended version of 
Pascal is called MODCAL. 

MODCAL is an acronym for Modular Pascal. Hence, one of its main fea- 
tures is a module facility, allowing for separate compilation, encapsula- 
tion, and libraries. 

In MODCAL heavy emphasis is placed on facilitating the construc- 
tion of machine- independent programs, while not disallowing access to 
low- level machine features where necessary. This is done through such fea- 
tures as type coercion (interpreting data as a different type than it is 
declared), Sizeof and Addr functions and procedure variables. 

A Hewlett Packard Corporate Standard exists for MODCAL. This document 
is organized to serve as a basis for the corporate standard. The table of 
contents reflect the main elements of this standard, required, adaptable, 
nonadaptable and experimental. 

Required is a list of extensions to HP Standard Pascal which must be 
in all Modcals in the coporation. Adaptable are a list of extensions which 
appear in some existing Modcals which may not be possible or advisable to 



put in another. However, the extension is easily adapted to another 
extension in the other MODCAL. Nonadaptable are extensions to HP Standard 
Pascal which are in an existing MODCAL today, but is so machine dependent 
that using it would make porting very difficult. Experimental features are 
those agreed to "be desirable. However, they have not yet been implemented 
or tested by an existing MODCAL. 

BCG MODCAL for the HP3000 and VCF contains some experimental features 
designed to allow the development of system code on the HP3000 that is of 
acceptable efficiency and transportable to VCF. There is support for the 
notion of an "object", which is found on HP3000, VCF, and Dawn architec- 
tures. Crunch packing allows data structures to be defined which will have 
the same bit offsets, no matter what computer the data was transfered to. 
Schema Array types was designed to allow a type safe way of passing, al- 
locating and slicing different sized arrays. 
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The syntax of the extensions are described by using a grammar notation 
with regular expressions. 

Terminal symbols are distinguished from other symbols by surrounding 
quotes, e.g. *if*. Nonterminals are represented by standard identifiers (a 
letter followed by zero or more letters, digits, or underscores) enclosed 
in angle brackets (*< >'). The following are other meta symbols used in 
the notation: 

-> means the nonterminal on the left is replaced with the 

sequence of symbols on the right 
* means zero or more occurrence of what precedes it 
+ means one or more occurrence of what precedes it. 
? means optional, zero or one occurrence of what precedes it. 
| means alternative, either an occurrence of what precedes it 

or an occurrence of what follows it. 
list means one or more occurrence of what precedes it separated 

by an occurrence of what follows it 
() parentheses to change binding rules 
(juxtaposition) 

means concatenation 

Operator precedence hierarchy 

() most binding 

?,*,+, list next, left to right 
(juxtaposition) next 
| least binding 

Examples : 

(a typical expression grammar) 

E -> E '+' T f _> »i» 
-> T 

T -> T '*' F 
-> F 

(The productions for a given nonterminal are collected together 
and the left part is factored out . ) 

A -> 'a' »b*»- 

a, ab, abb, abbb, abbbb, ... 

A -> 'a' 'b'+ *c' 

abc, abbe, abbbc, abbbbc, ... 

A -> *a* 'be' list '$' 

abc , abc$bc , abc$bc$bc , . . . 

A -> 'a' ('V | 'c')? *d» 
ad, abd, acd 
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A. HP MODCAL Standardized and Required Features 



1. HP Standard Pascal 

At the core of the MODCAL language is HP Standard Pascal. It makes 
up almost 90% of the language definition. HP Standard Pascal is not 
described in this document. A description can he found in the HP 
Standard Pascal document or the Pascal/3000 Reference Manual. 
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2. Modules 



Note: Implementation of this feature requires segmenter changes . 
The extensions to Modules from HP Standard Pascal (Implement, 
Definition, Readonly, Hidden, Qualified) have been recently defined and 
are not yet implemented in any MODCAL. These features are subject to 
modification, especially if implementation difficulties arise. 

A module is a program fragment which can be compiled independently 
and later used to complete otherwise incomplete programs. A module 
usually defines some constants, data types and variables, and 
procedures which operate on these data. Such definitions are made ac- 
cessible to users of the module by its export declarations. The module 
may itself make use of other module definitions by importing the other 
modules . 

Additional Reserved Words 

MODULE | EXPORT | IMPORT | IMPLEMENT | DEFINITION | 
READONLY I HIDDEN I QUALIFIED 



a. Programs and Modules 

The source text input to a compiler (complete unit of compila- 
tion) may be a program or a list of modules. The input text is ter- 
minated by a period. 



<compilation_unit> 
<prograi 
( <module> list ';* ) 



■> <program> V 



A module is a program fragment which can be compiled indepen- 
dently and later used to complete otherwise incomplete 
programs. An implementation may allow only a single module of 
input at a time, requiring multiple invocations of the com- 
piler to process several modules. It will probably be implemented 
this way in MODCAL /3000 and MODCAL/VCF cross compiler. 



b . Programs 

A MODCAL program is in form very similar to a proce- 
dure declaration. It differs in its heading, and in that 
modules may be declared and imported in the declaration part of the 
program's block. 

<program> 

-> <program_heading> <program_block> 
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<program_heading> 

-> 'PROGRAM' <identifier> 

( '(' <program_parameters> ')* )? ';' 

<program_parameters > 

-> <identifier> list *,' 

The identifier following the symbol program is the program name; 
it has no further significance inside the program. The program 
parameters denote entities that exist outside the program and 
through which the program communicates with its environment. 

These external entities (usually files) must be declared in 
the block which constitutes the program like ordinary local 
variables . 

Identifiers declared to be program parameters may be of any 
Pascal type. External entities which are not files are implementa- 
tion defined. 

The two standard files Input and Output must not be 
declared but have to be listed as parameters in the program heading, 
if they are used. The initializing statements Reset (Input) and 
Rewrite (Output) are automatically generated and need not be specified 
by the programmer. 



Examples 

PROGRAM copy (f,g); 

VAR f,g: FILE OF real; 

BEGIN 

Reset (f); 

Rewrite(g); 

WHILE NOT Eof(t) DO 

BEGIN 

g A := f A ; 

Pfc*(g); 

Get{t) 

END; 
END. 
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PROGRAM copytext ( input , output ) ; 

VAR ch:char; 

BEGIN 

WHILE NOT Eof( input) DO 
BEGIN 

WHILE NOT Eoln( input) DO 
BEGIN 
Read(ch); 
Write (ch); 
END; 
Reading Writeln 
END; 
END. 



c. The Program Block 

Identifiers declared in the <program_block> are said to have 
global scope; that is, they constitute the outermost level of the 
program's declaration structure. 

<program_block> 

-> <label_declarationjpart> <global_declaration>* 

<procedure_and_f unct ion_declarat ionjpart > < statement_part > 

<global_declaration> 

-> <constant_definition_part> 
-> <type_definition_part> 
-> <variable_declaration_j>art> 
-> <module_declaration> 
-> < import jpart> 

<module_declaration> 

-> <module> ';* 

< import j>art > 

-> 'IMPORT' ( <module_identifier> list ',' ) ';' 

<module_identifier> 

- > < ident if ier > 

Note: <label_declaration_jpart> , <procedure_and_function_declaration- 
part>, <statement_j>art>, <constant_defintion_part>, <type- 
defintion_j>art>, <variable_declarationjpart>, <identifier> 
are defined as in HP Standard Pascal. 

Program blocks, unlike the block of a procedure or function, 
may contain module declarations. A module is a collection of 
global declarations which may be compiled independently and later 
made part of a program block. Any module used by a program, whether 
appearing in the program's globals or compiled separately, must be 
named in an import list. Modules, and the entities they export, 
always belong to the global scope of a program which uses them. 
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A module cannot be imported before its definition has been com- 
piled, either as a global of the importing program or by a 
previous invocation of the compiler. This limits construction of 
mutually-referring modules. Access to separately compiled modules 
is discussed in Section le. 



d. Modules 

Although a module declaration defines data and procedures 
which will become globals of any program importing the module, not 
everything declared in the module becomes known to an importer. A 
module specifies exactly what will be exported to the "outside 
world" , and lists any other modules on which the module being 
declared is itself dependent. That is, a module has access only to 
those global enitities which it either declares itself or imports. 
The only exception is the program parameters INPUT and OUTPUT. The 
default values for predefined file procedures and functions are al- 
lowed. An error will be issued, usually by the linker/segmenter if 
INPUT or OUTPUT are used by a module and are not program parameters 
of the importing program. 

<module> 

-> 'MODULE' <module_identifier> . ';* ' 
<import_part>? <export_j>art>* 
< implement jpart > ' END ' 
-> 'DEFINITION' 'MODULE' <module_identifier> ';' 
<import_part>? <export_jpart>+ 'END' 

There are two ways to define a module. A module can be com- 
pletely defined at once using the first form above. A module 
defined this way must have an <export_part> . A module which did not 
export anything would be inaccessable , hence useless. A module can 
be defined in two parts, allowing for a certain amount of mutual 
referral of modules. This is done by using the 'DEFINITION' 'MODULE' 
declaration. Here, anything the module will export is defined. 
Hence the <export_part> is required as in the complete definition. 
Any modules needed for the export are listed in the < import jpart>. 
There is no <implement_part>. In order for the module to be com- 
pletely defined, a module definition must appear later in the program 
with an implement section. A warning will be issued for each incom- 
pletely defined module (has DEFINITION MODULE only) in a <com- 
pilation_unit> . This definition must not have an <export_part>, but 
it may have an <import_part>. (Allowing this second <import_part> 
has not been definitely decided. It is desirable because it allows 
mutually referring procedures in different modules. It also cuts 
down the amount of information loaded into symbol tables at compile 
time of the importing module. It is undesirable because the 
'Definition' 'Module' would not contain all the dependencies of that 
module . ) . 

The < import jpart>, as in a program block, is a list of module 
identifiers. The <export_j?art> defines constants and types, declares 
variables, and gives the headings of procedures and functions whose 
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complete specifications appear in the < implement jpart> of the module. 
It is exactly the items in the <export_part> which become accessible 
to any other code which subsequently imports the module. 

<export_part> 

-> T EXPORT' <qualifier>* ( <export_declaration> list ' ;' ) 

<qualifier> 

-> 'HIDDEN' | •QUALIFIED' | 'READONLY' 

<export declaration 

-> ( <constant_definition_part> | <type_definitionjpart> | 
<variable_declarationpart> )* 
( <routine_heading> List ';' ) '; T ? 

There can be multiple < export _j?art>s in a module. This allows 
for different qualifiers to be used for different exported entities. 
Multiple qualifiers can also be applied to an export declaration. 
For example, one may want to make a list of variables 'qualified' 
'readonly'. 

'Hidden' is a qualifier which only has meaning for types. Its 
use on other entities is ignored. A hidden type behaves as if only 
its name and size are known outside the module. When a hidden type 
is imported it can only be used in certain ways . Variables of the 
type can be declared. Other types can be declared equivalent to it. 
Variables, of the same type (identical or equivalent) may be assigned 
to each other (if assignable). Variables of hidden types may be 
passed by value (if assignment compatible as defined above) or 
reference. It is not possible to do anything which would require 
knowing the structure of the type, such as field references, index- 
ing, or assignment of expressions or constants. Any information 
about the internal structure of the type is not exported. Type coer- 
cion at any level except for structural compatibility is allowed. 

'Readonly' only applies to variables. Its use on other entities 
is ignored. A readonly variable may not be altered by assignment, 
nor passed as a Var parameter to a procedure or function. 

Names which are exported 'qualified' can only be used in the 
context of the name of the exporting module. This allows two 
modules to export names which have identical spelling to the same 
program or an importing program to have identically spelled names. 

Whenever the name of something exported from the module is used 
it must be qualified either with an explicit qualification 
(ntodulename ! entityname) or by a WITH statement. The semantics of the with 
statment is expanded from Pascal to allow module names to appear on the with list, syntax below 
(NOT IMPLEMENTED). The same scoping rules apply to the modules names as to the HP Pascal 
record expression list. Module names and record names can both appear in the same With list. 
The syntax of identifiers is expanded from Pascal to allow any iden- 
tifier to be qualified using the following syntax. 
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<with_list> 

-> ( ( <module_name> T) I <record_variable> ) LIST V 



<identifier> 
-> (<module namc> T )? <entity name> 



The modulename must be an imported module and entityname must be 
a constant, type, variable, procedure or function name exported by 
that module. 

NOTE; 'QUALIFIED* most likely will go away l 

NOTE: MODCAL/3000 will not support <variable_def inition_part> 
code generation in this release. 

The functionality or capability of the module — what it can 
do for an importer — appears in the <implement_part>. 

< implement_part > 

-> 'IMPLEMENT' <module_.capability> 

<module_capability> 

-> <declarationjpart> 

<procedure_and_funct ion_dec larat ion_part > 

Note: <dec larat ion _part> and <procedure_and_f unction - 
declaration_part> are defined as in HP Standard 
Pascal. If <dec larat ion jpart> is not empty then 
there must be a <procedure_and_function_declaration_part> 
also. 

Examining the syntax of <declaration_part> and 
<procedure_and_function_declarationj?art> reveals that the module 
capability may be empty. 

Any constants, types and variables declared in the implement 
part will not be made known to importers of the modules; they are 
only useful inside the module; outside of the module they are con- 
cealed. To make them known outside the module, they must be 
declared in the <export_j?art>. Variables of the <implement_part> of 
a module have the same lifetime as global program variables , 
even though they are concealed. An identifier which is concealed in 
one module may be reused as a concealed identifier in another 
module, and the two are totally disjoint. 

Any procedures or functions whose headings are exported by 
the module must subsequently be completely specified in its <im- 
plement_part>. In this respect the headings in the export part 
are like forward directives, and in fact the parameter list of 
such procedures need not be repeated in the <implement_part>. 
Procedures and functions which are not exported may be declared 
in the <implement_part>; they are known and useful only within the 
module . 
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In the following example, module "Symboltable" is declared 
to implement a generalized symbol table. This module defines 
the only operations which can be performed on a symbol table 
by exporting procedures "Add" and "Delete". The type of the 
"data" in the symbol table, and the maximum size of its "name" field, 
are provided by module "Lexic". Since Symboltable depends on 
Lexic, Lexic must be imported into Symboltable. Hence Lexic must be 
compiled first. 

MODULE Lexic; 
EXPORT 

CONST idsize = 16; 

TYPE alpha = PACKED ARRAY [1.. idsize] OF char; 
attr = RECORD 

level: integer; 
name : alpha 
END; 
IMPLEMENT 

{ empty <implement_part> since Lexic exports no procedures or 
functions } 
END; 

MODULE Symboltable; 
IMPORT Lexic; 
EXPORT 

PROCEDURE Add (ident: alpha; attr ib: attr); 
PROCEDURE Delete (ident: alpha); 
PROCEDURE Initsymboltable; 
IMPLEMENT 

TYPE symptr = ^symbol; 
symbol = RECORD 

link: symptr; 
name: alpha; 
data : attr 
END; 
VAR symtab: symptr; 

PROCEDURE Initsymboltable ; 
BEGIN symtab := NIL END; 

PROCEDURE Add (ident: alpha; attrib: attr); 
BEGIN 

{ body omitted for clarity } 
END; 

PROCEDURE Delete; (parameter list need not be repeated) 
BEGIN 

{ body omitted for clarity } 
END; 

END. 
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e. Libraries NOT IMPLEMENTED 



The modules Lexic and Symboltable as presented above illustrate that modules can always 
be compiled without reference to a program. In fact, a module can directly refer to variables of 
a program only if those variables are passed as parameters to procedures exported from the 
module. This restriction is not so severe as it may sound, since a module can be set up to ex- 
port global variables shared among the program and other modules. 

Separately compiled modules are called "library modules". To use library modules a 
program imports them just as if they had appeared in the program block: 

PROGRAM USER; 

IMPORT Lexic, Symboltable; 

VAR 

instring: alpha; 

characterize: attr; 

PROCEDURE Scanner (VAR incoming: alpha; VAR description: attr); 

BEGIN 
{ code to scan a symbol and set up its attributes } 

END; 
BEGIN 
END. 

When an import declaration is seen, a module must be found matching each name in the import 
list. If a module of the required name appears in the compilation unit before the import declara- 
tion, the reference is to that module. Otherwise, external libraries must be searched. 

The compiler option $SEARCH 'string' $ names the order in which externals libraries are 
searched. The parameter is a literal string describing the external libraries in an 
implementation -dependent fashion; usually the string will be a list of file names. This option may 
appear anywhere in a compilation unit, and overrides any previous SEARCH option. An im- 
plementation may have a default library which will be searched upon failure of all other libraries 
listed in 'string', such as the system library. 

Note: How SEARCH works in different implementations is not yet defined. 
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3. Try Recover Statement 

This statement defines error recovery code to be executed if an 
execution error is detected within a controlled statement. 



a. Try Recover Structure 

< s true tured_s tatement > 

-> <compound_s tatement > 
-> <conditional_statement> 
-> <repetitive_statement> 
-> <wi th_s tatement > 
-> <try_recover_statement> 

<try re cover_s tatement > 

-> *TRY' <statement list> *RECOVER* <unlabelled statement> 



b. Try Recover Semantics 

On detecting an error in the execution of <statement_list> the 
following sequence of events occur: 

1) The Escapecode for the error is set, 

2) the runtime environment is cut back to the enviroment in 
which the Try statement occurs, 

3) Execution is transferred to the <unlabelled_statement> 
after the Recover. 

If no error is detected in the execution of <statement_list> 
the <unlabelled_s tatement > is skipped-, and execution continues at the 
first statement following the Try statement. 

This construct divides the responsibilities of error recovery; 
error recovery which requires the enviroment in which the error oc- 
curs should use a trap handler provided by the system; for error 
reporting, the Try construct should be used. 

If an error occurs in the execution of the <unlabel- 
led_s tatement > , then execution is transferred to the enclosing Try 
statement. If there is no enclosing Try statement, then the 
program aborts. 

NOTE : Try Recover statements are not permited in code that will 
execute on the ICS, for MODCAL/VCF. 
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c. Bscape(i) 



Calling this predefined procedure indicates that a software er- 
ror has been detected. Execution is passed to the <unlabelled_stat~ 
ment> part of the first enclosing Try statement in the dynamic en- 
vironment. The parameter i is evaluated before control is passed and 
its value is made available to the Escapecode function defined in 
(3«d). Errors detected by hardware will cause an Escape to be ex- 
ecuted with a standard value. If Escape is called with no surround- 
ing try statement, then the action taken is to abort the program. 

WARNING ; Escape will be 2-U orders of magnitude more expensive 
then just entering and leaving a TRY statement normally, 



d. Escapecode: integer 

Calling this function returns the execution error number set 
by the most recent Escape call. If Escape has never been called the 
value zero (0) will be returned. If the <unlabelled statement> passes con- 
trol to the statement following the <try recover statement> in normal sequential 

manner, then the escape code will be reset to zero (0). 



e. Error Code Assignment 

The error code numbers are assigned using the following, conven- 
tion: The first 16 bits signifies which subsytem reported the error. 
The negative range has been reserved for HP products where the posi- 
tive range is for user. The second l6 bits indicates which error oc- 
curred. The constants for HP products are defined in two include 
files, one for Vision and one for 3000. 



f. Example 

The following program illustrates a use of the try 
statement for error recovery in a hypothetical system. This 
system defines a set of run time support procedures (only one is 
shown) and a user program which may cause errors. If an error is 
detected in the user program by the hardware or in the support 
procedure by software, an Escape will be generated which causes ex- 
ecution to continue in the recover section of the main program. This 
section prints out an error message. 
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PROGRAM xx ; 
CONST 

$Include 'ModCode.Pub.Sys'$ 



PROCEDURE support; 




BEGIN 




IF error THEN Escape ( ... ) 


END; 




PROCEDURE userprogram; 


BEGIN 




support 




END; 




BEGIN 




TRY userprogram 




RECOVER 




CASE Esoapeoode OF 




MinUser. .MaxUser: 


WrttelnC 


LanglRng 


WrttelnC 


SysStkOvf 


WritelnV 


SysIntOvf 


WritelnV 


SysIntDiv 


WritelnC 


SysFltOvf 


WritelnC 


SysFltUnf 


• VritelnV 


SysFltDiv 


: Writelnl* 


LanglNil 


t WritelnC 


LanglCase 


: Writelnl* 


LanglStrOvf 


: WritelnC 


FileErr 


: Writeln{' 


OTHERWISE 




Writeln( 'unknown 


error' ) 


END; 




END. 





'Software detected errors'); 

'Value range error'); 

'Stack overflow'); 

' Integer overflow' ) ; 

' Integer divide by zero ' ) ; 

'Real overflow'); 

'Real underflow'); 

'Real divide by zero*); 

'Nil pointer reference * ) ; 

'Case expression bounds error'); 

'String overflow'); 

'File I/O error'); 



The Escapecodes used in the 
constants for the HP 3000 or VCF. 



example are not the actual 
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4. Type Coercion 

Type coercion allows a programmer to circumvent the strong type 
checking of Pascal. The type coercion mechanism is a compile time 
operation (except in some cases of discriminated schema acccess) for ap- 
plying a different interpetation to the data value part of a data item 
(Appendix B) . 

a. Syntax/Semantics 

Type coercion has two (2) syntactic/semantic forms: 

Value Type Coercion (no restrictions) 

<factor> 

-> <target_type_id> '(* <expression> ')' 

This form of type coercion allows the value of an expression to 
be coerced to the target type. The evaluation of the expression may 
create a copy of the value to be coerced, thus any machine dependent 
addressing problems can be avoided. 

Variable Type Coercion (machine dependent addressing restrictions) 

<variable> 

-> <target_type_id> '(* <variable> ')' 

This form of type coercion allows the source variable to be 
coerced to the target type. Variable type coercion is permitted only 
for actual parameters. The source variable may not be addressable as 
the target type on a given machine (e.g. a byte as a word on the 
3000). When this occurs the type coercion is not allowed and an error 
is issued. Three cases that are very likely to result in this con- 
dition are: 

- Coercing any component of any CRUNCHED structure. 

- Coercing any component of any PACKED structure whose component 
type BitSizeof is less than the BitSizeof of a SU. 

- Coercing any component of any array whose component type 
BitSizeof is less than the BitSizeof of a SU. 



b. Compatibility Levels 

The use of type coercion can lead to the development of un- 
transportable system software. Additionally one form of type coer- 
cion can result in the use or modification of storage beyond that oc- 
cupied by the expression or variable coerced. These problems can be 
reduced by defining several levels of type coercion that progress 
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from safe and transportable to very dangerous and untransportable. 
The four (U) levels of type coercion defined in MODCAL based on the 
compatibilities in Appendix C are: 

STRUCTURAL - This level permits any data item to be coerced to 
any structurally compatible data type. This level simply permits 
renaming components. It is safe and fully transportable. 

REPRESENTATION - This level permits any data item to be coerced 
to any representation size compatible data type. This level requires 
identical BitSizeof values. It is unsafe only if reference types are 
involved (Appendix B) . It is transportable because all untransport- 
able uses are flagged as errors. 

STORAGE - This level permits any data item to be coerced to any 
storage size compatible data type. This level requires less or equal 
Sizeof values. It is unsafe and many untransportable uses will NOT 
be flagged as errors. 

NONCOMPATIBLE - This level permits any data item to be coerced 
to any data type, providing that syntactic/semantic form of type 
coercion is defined on the target machine. This level is very dan- 
gerous and no errors can be flagged. 

The safest level sufficient to permit the required type coer- 
cions is selected with the $Type_Coercion 'string'$ compiler option 
(Appendix A). 



c. Example 

MODULE MPE_File_Systera; 

IMPORT 

MPE_IO_System, 
MPE_Kernal; 

EXPORT 
TYPE 

Word = Shortlnt; 

WordArray = ARRAY [1..1] OF Word; 
TargetLen = Shortlnt; 
FileNumbers = Shortlnt; 

FUNCTION FRead ( 

FileNum : FileNumber; 
VAR Target : WordArray; 
TCount : TargetLen 
) : TargetLen; 
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IMPLEMENT . 
TYPE 

ArrayLen = 1.. 32767; 

FileSet = SET OF FileNurabers; 
CONST 

ValidFiles = FileSet [1..2551; 

FUNCTION BoundsCheck ( 

Origin : OffsetSU; 
Length : ArrayLen; 
ParmList : OffsetSU 
): BOOLEAN 
OPTION INLINE; 

BEGIN { BoundsCheck } 
$Type_Coercion 'REPRESENTATION^ 
IF (Word(GetDL) <= Word(Origin)) 

AND { Value Type Coercion } 

(Word (ParmList) > Word ( Or igin)+f*ec?( Length)) 
$Type_Coercion 'NONE'$ 
THEN 

BoundsCheck := TRUE 
ELSE 

BoundsCheck := FALSE; 
END; { BoundsCheck } 

FUNCTION FRead ( 

FileNum : FileNumber; 
VAR Target : WordArray; 
TCount : TargetLen 
): TargetLen; 
VAR 

BuffLen : ArrayLen; 
ByteLen : TargetLen; 

PROCEDURE FRead 1 ( 

READONLY BuffLen : ArrayLen 

) 

OPTION INLINE; 
TYPE 

WordSchema (Len : ArrayLen) = ARRAY [L.Len] OF Word; 
WordArray = WordSchema (BuffLen); 

PROCEDURE FRead_2 ( 

VAR Buffer : WordSchema 

) 

OPTION INLINE; 

BEGIN { FRead_2 > 
{ body omitted ) 
END; { FRead 2 } 
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BEGIN < FReadJ. > 
$Type_Coercion *NONCOMPATIBLE*$ 

FRead_2 (WordArray (Target)); { Varaible Type Coercion ) 
$Type_Coercion 'NONE'$ 

END; { FRead 1 > 



BEGIN { FRead > 
IF FileNum IN ValidFiles THEN 
BEGIN { have a file number } 
IF TCount < THEN 

BEGIN { byte target count ) 

ByteLen := -TCount; 

BuffLen := ByteLen DIV 2 + ByteLen MOD 2; 

END { byte target count ) 
ELSE 

BEGIN { word target count ) 

ByteLen := 0; 

BuffLen := TCount; 

END; { word target count } 

$Type Coercion 'REPRESENTATION^ 
IF BoundsCheck (OffsetSU(0//setpart (Addr (Target)) ) 
, BuffLen, AddtoOffset (GetQ , -6)) 
$Type_Coercion 'N0NE'$ 
THEN 

BEGIN < target in stack > 
FReadJ. (BuffLen); 
END { target in stack } 
ELSE 

FRead := 0; 
END { have a file number ) 
ELSE 

FRead := 0; 
END; { FRead } 



END. 
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5. Type Transfer function ReOrd 

Type transfer allows a programmer to convert the representation of 
one type into the representation of another type. Type transfer differs 
from type coercion when the representation of one value is changed to 
another representation. For example, converting an integer expression 
to an enumerated type. The predefined function ReOrd performs the type 
transfer. 

Function ReOrd (ordtype, expression): ordtype 

Example: 

PROGRAM ReOrd Example; 
TYPE 

numbers = (zero, one, two, three, four, five, six, seven, eight, 
nine) ; 

digit_range = . . 9 5 

VAR 

mnemonic: numbers; 
binary_value: digit_range; 

BEGIN 

binary_value := 7, 

mnemonic := ReOrd (numbers ,binary_value); 

(* mnemonic is now equal to enumerated value seven *) 

mnemonic : = ReOrd (numbers ,binary_yalue + 1) ; 

(* mnemonic is now equal to enumerated value eight *) 

Assert (mnemonic = ReOrd ( numbers, Ord (mnemonic), 0); 

END. 
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6. Procedural/Functional Variables 



a. Procedural Variables 



1. Type Procedure 

The Type definition syntax of Pascal is extended to allow 
the specification of procedural datatypes. This allows the 
creation and manipulation of procedural variables, and augments 
the parameter procedure mechanism already present in Pascal. A 
procedural type may be specified by using the keyword procedure 
followed by an optional parameter list as a type specifier. 
Variables of procedural types may be assigned procedures which 
have congruent parameter lists as defined in HP Pascal. Any pro- 
cedure assigned must have the same or wider scope than the vari- 
able it is assigned to. To assign a procedure to a procedural variable, the 
procedure name is used as a parameter to the Addr function. See example 
below. A procedural variable can be assigned NIL. This means no 
procedure has been assigned. 



2. Call 

The predefined procedure "CaZZ(Pvar, parm, parm, ...)" 
causes the indicated procedure to be called with the indicated 
parameters. Pvar is the identifier of a variable of type 
procedure. If during the execution of the procedure of a 
procedural variable, it accesses any non-local variables, then 
the variables accessed are the variables which were accessible at 
the time the procedure was assigned to the procedural variable. 
It is an error if Pvar has the value NIL or is undefined. It may 
not be possible to detect an undefined procedure variable. 
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3. Procedural Type Operations Model 

#__ * 

I I : = 

I V 
+ . + 

I Procedural | 

I Variable | 
+ -+ 

A I 

I I / ■ 

I := I (parm) / A2dr(Proc_Name) 

j J \ A2tfr(Proc Parm) 

I V \ • 

+ + 

I Procedural | 

I Parameter | 

+ + 

A I 

I I (parm) 
# # 



* Actual * 

* Procedure * 

I 
I 
I (parm) 

I 
V 

+ + 

I Procedure | 

I Parameter | 
+ + 

A I 

I I (parm) 
* « 



Proc Parm (...) } 
CaUlPrcdrlJVar, . . . ) > 
Call (Prcdrl Parm , . . . ) ) 



= { Proc Name ( . . . ) 



k. Example 



This program illustrates a use of a procedural type. First, 
type "p" is declared to be a procedural type with two real 
parameters. Subsequently, two procedures and one variable are 
declared which are compatible with this type. In the main 
program, the value of "pv" is set based upon some calculation and 
then the procedure "Call" is used to call the procedure referred 
to by "pv". Note that the identifiers in the parameter lists 
need not be identical. 



PROGRAM ProcVar( output); 

TYPE p = PROCEDURE (rl,r2: real); 

VAR pv : p; 

test : boolean; 

PROCEDURE procl(num,denom: real); 

BEGIN 

Wx*i £eZn(num/denom) ; 

END; 

PROCEDURE proc2(ml,m2: real); 
BEGIN 
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Writeln (ml*m2) ; 

END; 

BEGIN 

• • • 

IF test THEN 

pv := ADDR(procl) 
ELSE 

pv := ADDR(proc2); 
Call(¥v t 3.1 t k.3k)i 
END. 



b. Functional Variables 



1. Type Function 

The Type definition syntax of Pascal is extended to allow 
the specification of functional datatypes. This allows the 
creation and manipulation of function variables, and augments 
the parameter function mechanism already present in Pascal. A 
function type may be specified by using the keyword Function fol- 
lowed by an optional parameter list and a required colon and 
result type identifier as a type specifier. Variables of func- 
tion types may be assigned functions which have congruent parame- 
ter lists as defined in HP Pascal and identical result types. Any 
function assigned must have the same or wider scope that the vari- 
able it is assigned to. To assign a function to a function vari- 
able, the function name is used as a parameter to the Addbc func- 
tion. See example below. The reserved word NIL may be assigned 
to a function variable. This means that no function is assigned 
to it. 



2. FCall 

The predefined function "FCaZZ(Fvar, parm, parm, ...)" 
causes the indicated function to be called with the indicated 
parameters. Fvar is the identifier of a variable of type 
function. The type of the result of FCall is identical to the 
result type of Fvar. If during the execution of the function 
of a function variable, it accesses any non-local variables, 
then the variables accessed are the variables which were acces- 
sible at the time the function was assigned to the function vari- 
able. It is an error if Fvar is NIL or undefined. 
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3. Functional Type Opers 


itions Model 

/ 


« 
« 

1 

1 

A 

1 
* 

inc_Ni 




1 
1 


1 : = 
V 


**««**«*#**«« 


| Functional | 
| Variable | 


Actual * 
Function * 


A 
I 


1 
1 
:= | (parm) 

1 
V 


1 
1 


1 

1 

1 
1 


/ 

/ Aidr(Func_Name) 

\ Addr (Func Parm) 

\ .__ 


1 

I (parm) 

1 
V 


1 


\ 

... ) > 
l_Var,...) > = { Fu 
1 Parm , . . . ) } 


| Functional | 
| Parameter | 


Function | 
Parameter | 


A 

1 
*. 


1 

1 (parm) 

* 

Func_Parm ( 
FCall (Fnctn 
FCall (Fnctn 


i 

| (parm) 
# 

Miie (...) 



k. Example 

This program illustrates a use of a function type. First, 
type "f" is declared to be a function type with two integer 
parameters. Subsequently, two functions and one variable are 
declared which are compatible with this type. In the main 
program, the value of "fv" is set based upon some calculation and 
then the function "FCall" is used to call the function referred to 
by "fv". Note that the identifiers in the parameter lists need 
not be identical. 

PROGRAM FuncVar; 

TYPE f = FUNCTION (INT1,INT2: integer) : integer; 

VAR fv : f ; 

test : boolean; 
Answer : integer ; 

FUNCTION funcl(num,denom: integer) : integer; 
BEGIN 

funcl:=num DIV denom; 
END; 

FUNCTION func2(ml,m2: integer): integer; 
BEGIN 
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func2 : =ml*m2 ; 
END; 

BEGIN 

• * • 

IF test THEN 

fv := Addr(funcl) 
ELSE 

fv := A&£r»(func2); 
Answer: =FCalZ(fv, 3, U) ; 
END. 
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7. Special Predefined Functions 



a. Sizeof 

The Sizeof function returns the number of bytes needed to 
represent the data value part of a data item of the given type or the 
actual allocated size of a variable . 

Sizeof(t) Gives the number of bytes required to represent a 
variable of type t. 



Sizeofty) Gives the number of bytes required to represent variable v or the actual 
number of bytes allocated to represent variable v. 

Sizeoflp) Gives the number of bytes required to represent ANYVAR parameter p 
or the actual number of bytes allocated to represent the actual parameter passed to 
ANYVAR parameter p. 

Sizeof (tl, t2» ... ,tn) Gives the number of bytes 
required to represent a variable of type tl with tag field values t2, 

• » * t XIX • 

Sizeof {sl t s2, ... ,sn) Gives the number of bytes required to 
represent a variable of the discriminated schema type selected from 
the schema array si with discriminant values s2,..,,sn (Section D). 
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b. Addr 



The Addr function returns the reference part of the data item 
given to it as a parameter. 

Addz>(V) returns a pointer to the variable, V. It returns a 
pointer of the same type as NIL; that is, it is assignment compatible 
to any other pointer. Implementations may restrict its result to a 
pointer of type ^type of V. It is implemented this way in 
MODCAL/3000 and MODCAL/VCF. The pointer returned can be used as a pa- 
rameter to the ObjeotPart and OffsetPart pointer arithmetic 
functions . 
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B. HP MODCAL Standardized and Adaptable 
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C HP MODCAL Standardized and NonAdaptable 
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D. Experimental 



L Read Only Parameters 

The current parameter passing mechanisms of HP Standard Pascal supports only "call- 
by-value" and "call-by-reference", denoted by VAR. The first protects the actual parame- 
ter from modification, but requires making a copy. The second does not make a copy, but 
provides no protection for the actual parameter. 

MODCAL provides a third mechanism "call-by-value-reference", denoted READONLY. 
This mechanism protects the actual parameter from modification, and makes a copy if and 
only if the actual parameter is an expression or a constant. No modification of a variable 
(actual parameter) is permitted between the call to and return from a routine with a 
READONLY (formal) parameter. 

a. Read Only Parameter Definition 

The following shows the syntax for defining read only formal parameters. 

<formal parm section> 

-> <value parm spec> 

-> <variable parm spec> 

-> <read only_parm_spec> 

-> <procedure parm spec> 

-> <function_parm spec> 

<variable parm spec> 

-> »VAR' <identifier__list> ':'<type_id> 

<read only__parm spec> 

-> 'READONLY' <identif ier_list> ':' <type_id> 



b. Read Only Parameter Example 
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TYPE 

ArrType « ARRAY [L.10J OF INTEGER; 
CONST 

Art-Const - ArrType [10 OF 01; 
VAR 

ArrVar : ArrType; 

FUNCTION ArrFunc : ArrType; 
EXTERNAL; 

PROCEDURE Parm_Mechanisms ( 

Value Farm : ArrType; 

VAR Ref Parm : ArrType; 

READONLY Val_Ref _Parm : ArrType 

k 

EXTERNAL; 

BEGIN 

Parm Mechanisms ( 

ArrConst, {a copy is made} 

ArrConst, {an ERROR} 

ArrConst {a copy is made & address is passed} 

k 

Farm Mechanisms ( 

ArrVar, {a copy is made} 
ArrVar, {address is passed} 
ArrVar {address is passed} 

fc 

Parm Mechanisms ( 

ArrFunc, {a copy is made} 

ArrFunc, {an ERROR} 

ArrFunc {a copy is made & address is passed} 

); 

END; 
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2. Any Variable Parameters NOT IMPLEM ENTED 

The current "call-by-reference", denoted VAR, parameter passing mechanism of HP 
Standard Pascal requires any actual parameter be of the SAME TYPE as the formal 
parameter. 

MODCAL provides another mechanism "call-by-any-reference", denoted ANYVAR, 
This mechanism removes the SAME TYPE requirement while retaining all other require- 
ments of the "call-by-reference" mechanism (e.g. not passing components of PACKED or 
CRUNCHED structures). 

This feature permits some very dangerous programming practices. Some MODCAL im- 
plementation may provide for some safety by creating a "phantom" parameter who value is 
the SUSizeofits companion ANYVAR actual parameter. This "phantom" can then be used 
by checking code and the Sizeof, SUSizeof, and BitSizeof functions (see Section E 
and Appendix A). 

a. Any Variable Parameter Definition 

The following shows the syntax for defining any variable formal parameters. 

<formal parm section> 

-> <value parm spec> 

-> <variable parm spec> 

-> <anyvar parm spec> 

-> <procedure parm spec> 

-> <function parm spec> 

<variable parm spec> 

-> 'VAR' <identifier_list> V <type_id> 

<anyvar parm spec> 

-> 'ANYVAR' <identif ier_list> ':' <type_id> 

STRING must not be specified as the <type_id> when ANYVAR is specified. 
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b. Any Variable Parameter Example 

TYPE 

ArrTypel • ARRAY [1..10] OF INTEGER; 

ArrType2 - ARRAY U-201 OF INTEGER; 

ArrType3 « ARRAY [1..U] OF REAL; 
VAR 

ArrVarl : ArrTypel; 

ArrVar2 : ArrType2; 

ArrVar3 : ArrType3; 



PROCEDURE Parm_Mechanisms ( 
VAR Ref _Parml : ArrTypel; 
VAR Ref _Parm2 : ArrType2; 
ANYVAR Any_Ref _Parm : ArrType2 

h 

EXTERNAL; 

BEGIN 

Parm Mechanisms ( 

ArrVarl, {ok - std. Pascal} 

ArrVarl, {an ERROR} 

ArrVarl {ok / an ERROR for Any_Ref _Parm[ll]} 

f, 

Parm Mechanisms ( 

ArrVar2, {an ERROR} 
ArrVar2, {ok - std. Pascal} 
ArrVar2 {ok} 

); 

Parm Mechanisms ( 

ArrVar3, {an ERROR} 
ArrVar3, {an ERROR} 
ArrVar3 {ok / an ERROR for Any_Ref _Parm[12}} 

END; 
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PROCEDURE Same_As_ANYVAR_chkd ( 
VAR RefJParm : ArrTypc2; 

Ref Parm_Len : ObjectSize; 

ANYVAR Any_Ref_Parm : ArrType2 

); 

EXTERNAL; 

PROCEDURE Same__As_ANYVAR_unchkd ( 
VAR Ref_Parm : ArrType2; 
ANYVAR Any_Ref_Parm : ArrType2 

) 

OPTION Uncheckable_ANYVAR; 

EXTERNAL; 

BEGIN 
Same_As_ANYVAR_chkd ( 

$push, type coercion 'noncompatible'S 

ArrType2(ArrVarl), . 

$pop$ 
SUSizeof (ArrVarl), {allocated SUs for Ref_Parm} 
ArrVarl 

); 

Same_As_ANYVAR_unchkd ( 

$push, type coercion 'noncompatible'S 

ArrType2(ArrVarl), 
$pop$ 
{allocated SU's for Ref _Parm UNKNOWN} 
ArrVarl 

); 

END; 
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3. Schema Arrays NOT IMPLE MENTED 



Types in Pascal are used for determining the storage requirements of variables and for checking 
the compatibility of assignments and procedure/function parameters. This double duty use of the 
type concept is too restrictive for some areas of system programming. To alleviate some of these 
restrictions, schema arrays have been added to MOOCAL. 

A schema can be thought of as a collection of types; each member of the collection is related to 
the other members in that they each have the same overall structure. The structure of each type is 
that of an array with the same component type and packing. However, each array type has a dif- 
ferent index type. 

MODCAL permits a formal parameter of a procedure or function to specify that it will accept any 
actual parameter whose type is a member of a specified schema. In this way the procedure or func- 
tion can operate on a number of arrays with different index types, although only from the same 
schema. 

Through the use of schemata, MODCAL also allows local arrays declared within a procedure or 
function to have their bounds specified at runtime. This permits the procedure or function to adapt its 
activation storage requirements in cases where local work areas are required. 



a. Schema Array Definition 

<type definition part> 

-> <type_def_section> ? 

<type_def section> 

-> TYPE' 

( <type_def inition> | <schema_def inition> ) list ';* 

This says that the <type_definition_part> of a block is composed of any number of type 
and schema definitions. 

<new type> 

-> <new ordinal type> 

-> <new_structured_type> 

-> <new_pointer type> 

-> discriminated schema> 

This specifies that a <new_type> may be created by any of the means existing in Pascal or 
by selecting one of the members of a schema. Selecting one of the members of a schema is cal- 
led discriminating a schema, that is, specifying its actual index types. 

A schema -definition shall introduce an identifier to denote a schema. A schema defines a col- 
lection of <new_type>s whose type-denoter is a discriminated schema. 
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<schema_definition> 

-> <identifier> <formal_discriminant_part> 
'=• <array_schema> 

<formal_discriminant_part> 

-> '(• <discriminant_spec> list ';' ')' 

<discriminant_spec> 

-> <identifier_list> ':' <ordinal_type_id> 

<array_schema> 

-> ( "PACKED" | 'CRUNCHED' )? 
•ARRAY' •[' 

(<schema_Jndex_type> list ',') 
']' "of <component_type> 

<schema_index_type> 

-> ( <constant> | <discriminant_id> ) 

'..* ( <constant> | <discriminant_id> ) 

<discriminant id> 

-> <identifier> 

The occurrence of an identifier in a <schema_definition> of a <type_definition_part> shall 
constitute its defining point for the region that is a block. Each applied occurrence of that iden- 
tifier shall denote the same schema. Except for applied occurrences of the identifier as the 
domain type of a pointer type, the schema shall not contain an applied occurrence of the schema 
definition. 

NOTE: Currently, the <schema__index_type> must be an explicit subrange; therefore, it may 
not be the <type_id> of a subrange type. 

The above definitions add the mechanism by which to define a schema. The leading identifier 
on the schema -definition becomes known. A schema may not have any references to itself ex- 
cept when used as the domain of a pointer. Thus, a schema has the same scope as a type 
declared at the same place. 



b. Formal Discriminant Part 

The <formal_discriminant_part> in a schema definition shall define the formal discriminants. 
The occurrence of an identifier in a <discriminant_spec> shall constitute its defining point as a 
<discriminant_id> for that region of the program that is the following <array_schema>. 

For every <discriminant_id> in a <formal_discriminant_part>, there shall be at least one 

applied occurrence in the <array_schema>. The occurrence of a <discriminant id> in a 

<schema_index_type> of an <array_schema> shall specify that there is one type denoter 
which is a member of the schema for each allowed value of the <discriminant_id> such that all 
other <schema index type> values in the schema are the same. 

The <formal_discriminant_part> is used to associate identifiers with the schema so that the 
domain (members of the schema) can be determined. Every identifier used in the 
<formal_discriminant_part> must be used at least once in the following <array_schema>. In 
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the following, SnallVec is a collection of ten type denoters with index types "0.. 1","0..2", ... , 
"0..10". 

type 
Smalllnt = 1 .. 1 0; 
SmallVec (HighBound : Smalllnt) = 
array [0 .. HighBound] of real; 



c. Discriminated Schema 

A discriminated schema> selects one of the members of a schema as a <new-type>. The 

<discriminant_value>s are bound to their corresponding <discriminant_specs> in the <for- 

mal discrimfnant_part> of the schema. The number of discriminant values must be equal to the 

number of formal discriminants and each value must be assignment compatible with the type of 
the corresponding formal discriminant. 

<discriminated_schema> 

-> <schema_id> <actual discriminant -part> 

<actual discriminant part> 

-> '(' <discriminant_value> list 7 ')' 

<discriminant__value> 

-> <constant expression> | 

<read_only variable> 

A <discriminated schema> appearing in the declaration part of a block must have only con- 
stant or read_only variable discriminant values. This restriction assures that evaluation of dis- 
criminant values in the declaration part of a block can have no side effects. 

Any schema designated PACKED and denoting an array schema having its <schema_in- 
dex typo specifying as its smallest value a constant whose value is 1, and having as its com- 
ponent type a denotation of the char type, shall be a PAC schema. Any new type specifying a 
discriminated -schema which is a PAC schema shall be designated a PAC, and has all the special 
properties of a PAC defined in Pascal. 

A discriminated schema is a type denoter selected from the collection of type denoters in the 

schema. The values given in the <actual discriminant_part> are used (substituted) for the 

<formal discriminant_part> in the <array schema>. Thus the discriminated schema 

"SmallVec(7)" selects the member of the schema which is structurally compatible to (but not the 
same as) the array: 

ARRAY [0 .. 7] OF REAL 

An attempt to specify the schema as "SmallVec(1 1)" will result in an error because the value 
1 1 is not assignment compatible with the type of Highbound. 

It must be noted that although a discriminated schema> is equivalent in structure to an ar- 
ray type, it is never the same (in the sense of Pascal type compatibility). Moreover, two dis- 
criminated schemas that specify the same discriminant values are not the same. 

Any discriminated schema> having the same number of components of structurally 

compatible types with the identical packing are said to be STRUCTURALLY compatible. Any 
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unpacked arrays or unpacked discriminated -schemas having the same number of components of 
structurally compatible types are said to be structurally compatible (see Section A and Appendix 
C). 

Any <discriminated_schema> with <read_only_variable>s in Its <ac- 
tual_discrimlnant_part> . denotes a type that may be used only in a 
<variable_declaration_part> or a type coercion. 



d. Schema Discriminants 

<factor> 

-> <variable_access> 

-> <unsigned_constant> 

-> <function_designator> 

-> <set_constructor> 

-> '(' <expression> ■)' 

-> 'NOT' <factor> 

-> <schema discriminant> 

-> <read only variable> 

<schema_discriminant> 
-> <variable_access> '.' <discriminant_id> 

<read_only_variable> 
-> <variable_access> 

The schema discriminants for a discriminated schema value are simply the values that were 
used to satisfy the formal discriminants in the declaration of the discriminated schema which is its 
type. The notation to access this value uses the name of the formal discriminant from the 
schema declaration. For example, consider the following schema, discriminated schema and dis- 
criminated schema value: 

TYPE 
Smalllnt = 1..10; 

Sehema(Start,Length : Smalllnt) = ARRAY[Start..Length] OF 
INTEGER; 

DiscSchema = Schema(1,5); 
VAR 
X : Smalllnt; 
DiscSchemaValue : DiscSchema 

The actual discriminant values for DiscSckemzValue are 1 and 5, accessible by the nota- 
tion DiscSchemaValue. Start and DiscSchema Value.Length, respectively. 

Because a factor can never appear as a target of an assignment, the discriminant may never 
be altered. The value of the discriminant could be thought of as a "read only variable" associated 
with the variable or parameter. The vector addition example above shows the use of 
<schema discriminant>s. 
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e. Schema Array Parameters 

Discriminant values can be constants or read only variables (variables whose value cannot be 
altered); thus discriminant values are constant over the entire scope of a discriminated schema. 
The following shows the syntax for defining read only variables and schema array formal 
parameters. 

<formal_parm_section> 
-> <value_parm__spec> 

-> <variable parm_spec> 

-> <read_only._parm_spec> 

-> <procedure parm_spec> 

-> <function_parm_spec> 

<variable_parm_spec> 

-> 'VAR' <identifier__list> ':' 

( <type_id> | <schema_id> ) 

<read only parm spec> 

-> 'READONLY' <identifier_list> ':' 

( <type id> | <schema id> ) 

These productions deal with read only parameters and schema parameters. Read only para- 
meters are discussed in the next section; this section deals exclusively with schema parameters. 

A variable may be passed into a procedure or function whose type denoter is a member of a 
schema. When a schema identifier is specified, the parameter may be of any type which is a 
member of that schema. 

If the formal parameters are specified in a <variable_parm_spec> in which there is a 
<schema_id>, the type possessed by the actual parameter shall be itself a parameter that was 
specified with the same <schema_id>; and the type possessed by the formal parameter shall be 
distinct from any other type. 

This states that a formal parameter that was declared with a schema will only permit the ac- 
tual parameter to be of a type which is a member of the same schema. A formal parameter which 
is a schema may in turn be passed on as a variable-parameter utilizing the same schema. 

If the form of the parameter list includes an <identifier list>. then all the actual parameters 

must be of the same type (only for variable parameters); this is true for schemas as well as other 
types. 

The following example adds two vectors, element by element, and returns the result in the 
first parameter. 
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PROCEDURE AddVectors (VAR A.B.C : SmallVec); 
VAR 
i : Smalllnt; 

BEGIN 

Assert (A.HighBound = B.HighBound, 1); 
Assert (A.HighBound = C.HighBound, 2); 
FOR i ~ TO B.HighBound DO 

A[i]:=B[i]+C[i]; 
END; 



f . Read Only Parameters 

The productions from the previous section state that read only variables are defined by 
<read__only_parm_spec>s (read only variables are also exported by modules). The occur- 
rence of an identifier in the <identifier_list> of a <read_only_parm_spec> shall constitute its 
defining point as a read only variable for the region that is the block, if any, of which it is a formal 
parameter. 

All parameters that are specified with the read only mechanism are identified as being read 
only variables; this permits them to be limited to being factors within the block. The actual pa - 
rameter shall be an expression. A formal parameter declared with a schema as its type 
specification and occuring in a single <read_only_parm_spec> shall possess an array type 
which is distinct from any other type. The type possessed by the actual parameter shall be a 

discriminated schema designating the same <schema id> as the formal parameter or the ac - 

tual_parameter shall be itself a parameter that was specified with the same schema identifier; or 
the actual parameter must be a PAC and the formal parameter must designate a PAC -schema; or 
the actual parameter must be of the same type as the formal -parameter. 

For an actual parameter that denotes a read only variable access, there shall be no assigning 
reference during the activation of the block of the procedure or function to the actual parameter. 

This introduces a parameter mechanism into MODCAL that requires that the actual_parameter 
may not be altered during the activation of the associated procedure or function. Any expression 
may be specified by the actuai_parameter. Thus, the mechanism achieves not only protection of 
the actual -parameter but also permits literal strings or value type coercions to be specified. 



g. Discriminated Schema Access 
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<discriminated_schema_access> 

-> <dis criminated schema value> 

•[• <schema_access_list> ']' 

<discriminated_schema value> 

-> <variable_access> 

<schema_access list> 

-> ( <index_expression> V )* <schema_access_expr> 

<schema_access_expr> 

-> <disriminant value> 'FOR' <discriminant_length> 

<index_expression> 
-> <expression> 

<discriminant length> 

-> <expression> 

NOTE: Only <schema_access_List> -> <schema_access_expr> will be permitted in the 
next several releases. Also, the following restrictions are being considered: 1) Discriminated 

schema access only permitted with one -dimensional schemas and 2) <discriminant length> must 

be a constant (e.g., DiscSchemaVaiue[x FOR 5]). 

A <discriminated_schema_value> is any variable, parameter, or constant which has a dis- 
criminated schema as its type denoter. A <discriminated_schema_access> selects a con- 
tiguous sequence of the components of a <discriminated_schema value>. This contiguous se- 
quence has a type denoted by another member of the same uniquely discriminated schema as the 
<discriminated_schema_value>. A contiguous sequence of components of any array or <dis - 
criminated_schema> type is just a sequence of components that occupy consecutive storage 
units. That is, for array types stored in row major order, any subrange of the last index type of 
the array defines a contiguous sequence of its components. A subrange can also be specified for 
an index type other than the last one. In this case, no following index types may be specified; the 
entire ranges of the following index types are used in order to ensure contiguity. Consider the 
following schema, discriminated schema and discriminated schema value: 

TYPE 
Smalllnt = 1..10; 

Schema 2D(L1,U1,L2,U 2 : Smalllnt) = {A schema) 
Array[L1..U1,L2..U2] OF INTEGER; 

Square = Schema 2D( 1,5,1,5); {A disc, schema} 

VAR 
Square 1 : Square; {A disc, schema value) 

The discriminated schema access Squarel[4, 3 FOR 3 J specifies the 3rd through 5th 
components of the 4th row of Square! Squarel[2 FOR 2] specifies the entire 2nd and 3rd 
rows of Squarel Clearly, if a schema access expression (n FOR mi were permitted for the 
second index position of this second example, the selected components would not be contiguous. 

Also a discriminated schema access is a discriminated schema value; its type is a member of 
the same schema, but its index types are a subrange of the corresponding index types of the 
original discriminated schema value. For example, Squcupel[4y 3 FOR 3] is a discriminated 
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schema value; its type is a discriminated schema with its first index type the subrange 4. . 4 and 
its second index type the subrange 3. .5. This discriminated schema is still a member of the 
schema SchemaBD. 

It was mentioned above that a discriminated schema access is only permitted with a uniquely 
discriminated schema. A uniquely discriminated schema is defined as any schema definition 
having two formal discriminants in the formal discriminant part for each schema index type in the 
array schema. This means that each of the upper and lower bounds of each index type has its 
own formal discriminant. So the schema SchemxZD is uniquely discriminated, whereas the 
schema SmallVec from the preceding discussion of formal discriminants is not. We required ear - 
tier that a discriminated schema access itself be a member of the original schema. This is not 
guaranteed when the discriminated schema is not uniquely discriminated. To see this, consider 
again the schema SmallVec. 
TYPE 
Smalllnt = 0..10; 

SmallVec(HighBound : Smalllnt) = ARRAY[O..HighBound] OF REAL; 
VAR 
Vec7 : SmallVec(7); 

Now if we were allowed to use Vec7 in a discriminated schema access, say Vec7[Z FOR 
4], then the type of the resulting discriminated schema access would not be a member of the 
schema SmallVec. Any member of SmallVec must have Oas its lower bound; however, the 
type of Vec7[3 FOR 4] has 3 as its lower bound. Clearly, this is not a member of the schema 
SmallVec 

The following example illustrates the use of discriminated schema access, declaration of a 
uniquely discriminated schema, and schema array parameters. 

PROGRAM Discrm_Schema_Access; 
TYPE 

IndexType = 1..12; 

Schema (L1.U1.L2.U2 : IndexType) = 
ARRAY [L 1 ..U 1 , L 2..U 2] OF ComponentType; 

DiscrSchema 1 = Schema ( 1 , 1 0, 1 , 1 2); 

DiscrSchema 2 = Schema ( 3, 3, 2, 8); 

DiscrSchema3 = Schema (2,4,1,1 2); 
VAR 

DiscrSchema lvalue : DiscrSchema 1; 

DiscrSchema 2 Value : DiscrSchema 2; 

DiscrSchema 3 Value : DiscrSchema 3; 

PROCEDURE SchemaParm (VAR DiscrParm : Schema); 
BEGIN 
END; 
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BEGIN 

SchemaParm (DiscrSchema 1 Value); 
(•DiscrParm.L 1 = 1 

DiscrParm.UI = 10 

DiscrParm.L2 = 1 

DiscrParm.U2 = 12*) 

SchemaParm (DiscrSchema 2Value); 
SchemaParm (DiscrSchema 1Value[ 3, 2 FOR 7]); 
(*DiscrParm.L 1 = 3 

DiscrParm.U 1 = 3 

DiscrParm.L 2=2 

DiscrParm.U 2 s= 8*) 

SchemaParm (DiscrSchema 1Value[ 2 FOR 3]); 
SchemaParm (DiscrSchema 3Value); 
(*DiscrParm.L1 = 2 

DiscrParm.UI = 4 

DiscrParm.L 2=1 

DiscrParm.U 2 = 12*) 
END. 



h. Example 

PROGRAM ShowSchemaArrays; 
CONST 

maxsize =25; 

$lnclude 'other.consts.example' $ 

TYPE 
Size = 1.. Maxsize; 
Matrix(Row,Col : Size) = ARRAY [1.. Row, 1.. Col] OF Real; 

VAR 
A:Matrix(10,5); 
B:Matrix(5,10); 

PROCEDURE MatrixMultiply ( 

VAR A : Matrix; 

READONLY B : Matrix); 
VAR 

I.J.K : Size; 

T : real; 

C : Matrix(A.Row,B-Col); 
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BEGIN (* MatrixMultiply *) 
IF (A.Row = B.Col) 
OR 
(A.Col sb B.ROW) 
THEN 
BEGIN 

FOR I := 1 TO A.Row DO 
FOR J .- 1 TO B.Col DO 
BEGIN 
T ~ 0.0; 
TRY 
FOR K := t TO A.Col DO 
T := T + All. J] * B[K. J]; 
RECOVER 

case EscapeCode of 
FltPtOverflow: 

T :«s MaxReal; 
FltPtUnderflow: 

T := MinReal; 
OTHERWISE 

Escape {EscapeCode); 

END; 
C[I.J] := T; 
END; 
FOR I := 1 TO A.Row DO 
FOR J — 1 TO A.Col DO 
A[I,J] := C[I,J]; (*return funky results*) 
END 
ELSE 

Escape (BadMatrix); 
END; (* MatrixMultiply *) 

BEGIN 

MatrixMultiply (A,B); 
END. 
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4. Objects 



a. Introduction 

The HP 3000 and Vision Computer families are segmented 
machines. It is impossible to place Pascal variables in data 
segments/objects^ >o the type classes object and offset have been 
placed in MODCAL to correct this deficiency. 

An object is a contiguous sequence of SU's numbered from 
zero to some maximum. An object may be dynamically created and 
destroyed, and its lifetime is independent of any Pascal 
scope. Upon creation, an object is given an initial size and a 
maximum size in SU*s. An object may grow up to its maximum size and 
may shrink down to zero. Each object has a compile-time defined 
storage area in its first n SU's, where n is the size of this 
static area (which may be 0, e.g. RECORD END). The remaining space 
in the object may be used as the programmer chooses. 

A pointer in MODCAL is composed of two parts: an object 
specifier and an offset. An object specifier is declared and 
used much in the same way that pointers are used. The symbol 
used for dereferencing an object specifier is '%*, while the 
symbol used for dereferencing pointers is '**. A dereferenced ob- 
ject specifier with an offset forms a pointer. An offset is useless 
in referencing data without a dereferenced object specifier. 

Note: Heap pointers in MODCAL/3000 do not have the same under- 
lying representation as an object, offset pair. 



1+8 



Objects 



b. Syntax Additions 

Objects require the following changes to the syntax charts for 
Pascal: 

variable 

+- > variable id >+ 

I I 

+ > field id >+ 

I I 

+--> object var -> '%* -+-> *(' -> offset var -> *)' ~ >+ 

I I 

V V 

+< + + 

I 

+< . . + 

I I 

+ — > '[* -+ — > expression -+ — > ']* >+ 

I " I I 

II V | 

I +< V + I 

I I 

+— > '.' > field id >+ 

I I 

+ > »*» >+ 

I 
V 

or in grammar notation: 

<variable> 

-> «object_var> '%' ( *(* <offset__var> •)• )? 

<object_yar> 

-> <variable> 

<offset_var> 

-> < variable > 
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type 



— + — > simple type >+ — > 

I 

+ +_+ — > »~» +-> type id ->+ 

I II I 

+<— 'PACKED' — + +--> '%' ■ + | 

I II II 

+<- 'CRUNCHED' -+ +-> 'OFFSET' -> 'TO' -+ | 

I I 

+-- > 'ARRAY' — > '[* -+— > simple type -+--> ']' -+ | 

I A III 

I +- V <— - + I I 

I I I 

I +< + I 

I I I 

| +--> 'OF' --> type >+ 

I 

+--> 'FILE' — > 'OF' --> type — >+ 

I I 

+ — > 'SET' — > 'OF' --> simple type — >+ 

I 

+--> 'RECORD* — > field list — > 'END' >+ 

I I 

+ — > schema arrays >+ 



or in grammar notation: 

<type> 

- > < s implejtype > 

-> ( 'PACKED' | 'CRUNCHED' ) <type> 

-> ( **• | '%* | 'OFFSET' 'TO' ) <type id> 

-> 'ARRAY' '[* ( <simple_type> list \ T ) ']' 

'OF' <type> 

-> 'FILE' 'OF' <type> 

-> 'SET' 'OF' <type> 

-> 'RECORD' <field_list> 'END' 

-> <schema_definition> 

-> <discriminated_schema> 

< statement > 

-> 'WITHOBJECT' ( (<object_var> '%') list ',' ) 
'DO' <statement> 
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c. Object /Off set Model 



Static Area 



VAR objl : % type_namel; 
obj2 : % type~name2; 
off : OFFSET~T0 type_namel; 
ptrl : * type_namel; 
ptr2 : A type_narae2; 

objl ====>++ ++ - 

I II objl* || 

I II II 

I IK type narael } 1 1 

off |+ r + 1 

I I i 

I I I 

I I I 

===>!+ + 1 

M objl%(offr II 

II II 

IK type namel }|| GetObjectSize (objl) 

1+ - + 1 

I I 
ptrl ====>++ ++ 

II ptrl A || 

II II 

I I { type namel } 1 1 

1+ ~ + 1 

I I 

+ + 



obj2 ====>++— 

obj2# 



off 
I 
I 

I 



I { type name2 } | | 
+ - + 1 



I 



Static Area 



+ + 1 

| obj2%(offr II 

| || Get0bjectSize{ohj2) 

I ( type namel } | | 
+ - + 1 



ptr2 ====>++ ++ 

I ptr2^ 1 1 

I ( type name2 } | | 

1+ " + 1 
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d. Semantic Definition 

Consider the following MODCAL block: 

TYPE 

Foo = RECORD 

intl, int2: integer 
END; 

Obj = *Foo; 

Offsetlnt = OFFSET TO integer; 

VAR 

systable : Obj; 

f : Foo; 

off : Offsetlnt; 

errcode : integer; 

BEGIN 

CreateObject ( systable , 100 , 100 , errcode ) ; 

IF errcode = THEN 

BEGIN 

systable*. intl := 1; 

systable*. int2 := systable* . intl ; 

f := systable*; 

MakeOffset ( of f , SUSizeof {Foo ) ) ; 
WITHOBJECT systable* DO 

off* := 7; 
END; 
END; 

This declares systable as an object variable of type *0bj* 
with a static area containing two integers. The notation 
systable* denotes systable *s static area and is a variable of 
type Foo. The notation systable* (off ) denotes a pointer of type 
^Integer. The first statement of the program stores a *1* into 
the first integer of the static area, and the second statement 
copies the value of the first integer into the value of the second 
integer in the static area. The third statement copies the entire 
static area into f. The final two statements have the effect of 
placing a seven following systable 's static area. See the sec- 
tion on pointer arithmetic for the definition of MakeOffset. 

As an abbreviated notation, a dereferenced object variable, sys- 
table*, can be used as a variable in a Withobject list. In this use, 
one can denote an offset in systable or part of systable 's static 
area without having to qualify the offset or static area field 
name with systable for the scope of the Withobject statement. 

Note: On the 3000, only one object variable can be used in a 
Withobject list. 
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The assignment and compatibility rules for objects and 
offsets are the same as for pointers in Pascal. 
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e. Object Manipulation 

The following predefined procedures which operate on 
objects have been defined. 



PROCEDURE Createobjeot ( 

VAR object : objectform ; 

size : Object Size; 

maxsize : ObjectSize; 

VAR status : errorcode) ; 

The var parameter object contains the object number of 
the object created. The parameter size is the initial al- 
location of space given to the object, and the parameter maxsize 
is the maximum number of storage units that the object may 
grow to. The var parameter status is an integer which indi- 
cates the success of the operation (zero (0) = success). 



PROCEDURE AlterObjectsize ( 
object : objectform ; 
newsize : ObjectSize; 
VAR status : integer); 

This predefined procedure alters the size of an object. 
The var parameter object is the object whose size is to altered, 
the value parameter newsize is the new size of the object, and the 
var parameter status is an errocode which indicates the success 
or failure of the operation (zero (0) = success). If the newsize is 
greater than the maxsize given in the call to Createobject, then the 
results are system dependent. 



PROCEDURE DestroyObjeot ( 
VAR object : objectform ; 
VAR status : integer); 

This predefined procedure returns an object to the operating 
system. The var parameter object is the object to be returned, and 
the var parameter status is an integer which indicates the success 
or failure of the operation (zero (0) = success). 

Because target machines may provide more powerful operations 
on objects through operating system intrinsics or a user may want to 
gain access to an object maintained by the operating system or some 
other user, the following operation is provided. 



PROCEDURE AttachObject ( 
VAR object : objectform ; 

id : objectid; 
VAR status : integer) ; 
or 
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PROCEDURE AttackObject ( 
VAR object : objectform ; 
id : object id ) ; 

This predefined procedure places the value parameter id into the 
var parameter object, and returns the success or failure of the 
operation in the var parameter status (zero (0) - success). It is 
assumed that id is the object number of an already existing operating 
system object. 



FUNCTION Stack 
: objectform ; 

This predefined function returns an object that corresponds to 
the active process stack. The type of the object returned is struc- 
turally compatible with any object having a fixed part with Sizeof 
equal to zero. 



FUNCTION CurrentObject 
i objectform ; 

This predefined function returns an object that corresponds to 
the object refence of the most resently executed WITHOBJECT clause. 
The type of the object returned is structurally compatible with any 
object having a fixed part with Sizeof equal to zero. MODCAL/3000 
will insure that DB points to this object when any procedure or func- 
tion with a directive of EXTERNAL SPL is called. 



FUNCTION GetObjectld ( 

Object: objectform 

) : objectld; 

This predefined function returns the "object id" of the object 
denoted by the value parameter object (basically the inverse of 
AttachObject) . 



FUNCTION GetObjectSize ( 

Object; objectform 

): ObjectSize; 

This predefined function returns the number of SU's currently 
allocated to the object denoted by the value parameter object. If 
Stack is passed to GetObjectSize the size of the currently accessable 
area is returned (HP3000 : S-DL, VISION : S-SB) . 

f . Pointer Arithmetic 

The following predefined functions are provided to permit point- 
er arithmetic. The types ObjectSize and ObjectDelta are defined in 
the portability foundation section. 
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PROCEDURE MakeOffset ( 

VAR offsetvar : offsetform ; 
value : ObjectDelta) ; 

The var parameter offsetvar is made to point to the variable 
beginning at the storage unit position given in the value pa- 
rameter value. 



FUNCTION AddToOffset ( 

offsetvar : offsetform ; 
delta : ObjectDelta 
): offsetform ; 

This predefined function adds the value parameter delta to the 
value parameter offsetvar and returns this value. The type of offset 
returned is identical to the type of the offset parameter. 



PROCEDURE MakePointer ( 

VAR ptr : pointerform ; 
object : object form ; 
offset : offsetform ) ; 

This procedure constructs a pointer from the value parameters 
object and offset, and returns the constructed pointer in the var pa- 
rameter ptr. The reference type of the offset type and the pointer 
type must be identical. MODCAL/3000 requires that the object parame- 
ter be equal to the object returned by Stack. 



PROCEDURE BuildPointer ( 
VAR ptr : pointerform ; 
object : Objectld; 
offset : ObjectDelta); 

This procedure constructs a pointer from the value parameters 
object and offset , and returns the constructed pointer in the var pa- 
rameter ptr. MODCAL/3000 requires that the object parameter be equal 
0. This procedure is intended to replace a sequence of: AttaohObject , 
MakeOffset > MakePointer. 



FUNCTION AddToPointer ( 

ptr : pointerform ; 
delta : ObjectDelta 
): pointerform ; 

This predefined function returns a pointer value which 
points delta storage units away from where the value parameter ptr 
originally pointed. The type of the pointer returned is identical to 
the type of the pointer parameter. 
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FUNCTION OffsetPart ( 

ptr : pointerform 
): off set form ; 

This predefined function returns the offset part of the pointer 
parameter. The offset has the same reference type as the pointer. 



FUNCTION ObjectPart ( 

ptr : pointerform 
) : object form ; 

This predefined function returns the object part of the pointer 
parameter. The object has the same reference type as the pointer. 



The meta-types " pointerform " , " objectform " , and " offsetform " are 
used above to indicate that these predefined procedures and functions 
will accept and return any form of pointer type, object type, or off- 
set type. 
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5. Crunch Packing 



The word 'crunched* has been added to the reserved word list 
to indicate that the components of a structured type are allocated 
contiguously, first to last in a bit -aligned fashion. Components may 
cross any arbitrary machine storage unit boundry. The word 'crunched' 
may be substituted for the word 'packed'. 

Example 

TYPE t = CRUNCHED RECORD 
a : .. 15; 
b : -32767 .. 32767; 

c : #0 . . #255; {currect Char subrange} 
END; 

MSB LSB 

|a a a a|b b b b b b b b b b| 

|b b b b|c c c c c c c c|XXX| 

Layout of type crunched type t (assuming 16 bit SUs) 
(note: the value of XXX is undefined) 

The number of bits used to represent each component of a crunched 
structured type is the minimum needed to represent the values associated 
with that component. The calculation for the minimum number of bits is: 

Integer Based Types (lo . . hi) 
if (lo <> 0) or (hi <> 0) 

then ceil(log2(max(abs(lo),succ(abs(hi))))) + ord(lo < 0) 
else 1 

Character & Enumerated Based Types (lo .. hi) 
if ord(hi) > 

then ceil(log2( succ(ord(hi) ) )) 
else 1 

Set Types (SET OF lo . . hi) 
succ(abs(ord(hi) - ord(lo))) 

Record, Array & Nonimbedded Descriptor Types 

The sum of the minimum number of bits to represent all 
of the components (consider largest variant only). 

For example, it would take only four bits to represent a component 
with the subrange type . . 15 or the subrange type lU . . 15 , but it 
will take five bits to represent a component with the subrange type -1 
.. Ik. 
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The restrictions which apply to packed types also apply to crunched 
types. This means that record comparisons are not allowed. In addi- 
tion, it is not legal to pass by reference a component of a crunched 
structured type to any procedure or function. 

The primary purpose of crunch packing is to provide an implementa- 
tion invariant specification of the data item type to data item 
representation mapping. The implementation invariant requirement neces- 
sitates the restrictions listed below. 

No file types or any structured type containing any file, real, 
string, or reference types may be crunch packed. 

Any structured type contained in a crunched structured type must be 
crunch packed also. 

No structured type containing an Integer or Char may be crunch 
packed. The range of these predefined types may be changed in the fu- 
ture. The user can always replace the types Integer and Char with a sub- 
range type. 

NOTE: Crunched structures are temporarily required to be less than 
or equal to 20U8 words (16 k-bits) in length. 
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6. MoVe_R_to_L &. MoVe_L_to_R Predefined Procedures 

The Move predefined procedures provide generalized array structure 
copying mechanisms in MODCAL. The syntax of the Move procedures is 
identical to the syntax of the StrMoVe predefined procedure. The seman- 
tics of the Move procedures are presented below in a Meta-MODCAL form. 
The lower case identifiers denote the meta-parameters of the semantics. 
The actual parameters to a Move are (structurally) type coerced to match 
the formal parameters by the compiler. 

TYPE 

COUNT_RANGE = 1 .. MAXINT; 

SOURCEJTYPE (MIN, MAX i INTEGER) ■ 

source_jpacking ARRAY [MIN .. MAX] OF component_type ; 

TARGET JTYPE (MIN, MAX : INTEGER) = 

target jpacking ARRAY [MIN .. MAX] OF component_type ; 

PROCEDURE move r to 1 move 1 to r ( 



MOVE_CNT 
READONLY SOURCE 

SOURCE_BIAS 
VAR TARGET 

TARGET_BIAS 
) OPTION INLINE; 
VAR 

LOOP CNT, 

LOOP _ LIMIT : COUNT RANGE; 



INTEGER; 

SOURCEJTYPE; 

INTEGER; 

TARGETJTYPE; 

INTEGER 
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BEGIN { MOVE Semantics > 
IF MOVE_CNT > THEN 

BEGIN { Move Some Components } 

LOOP_LIMIT := Pred (MOVE_CNT); 

Assert (SOURCE_BIAS >= SOURCE. MIN, 0, move_error) ; 

Assert (SOURCE_BIAS + LOOP LIMIT <= SOURCE. MAX, 0, move_error) ; 

Assert (TARGETJBIAS >= TARGET. MIN, 0, move_error) ; 

Assert (TARGET_BIAS + LOOP_LIMIT <= TARGET. MAX, 0, move_error) ; 

CASE move r_to_l move 1 to r OF 
MOVE_R_TO_L: 

FOR LO0P_CNT : = LOOPLIMIT D0WNT0 DO 
TARGET [L00P_CNT+ TARGET BIAS] := 
SOURCE [LO0P_CNT + SOURCE_BI AS ] ; 

MOVE_L_TO_R: 

FOR LO0P_CNT := TO LOOP_LIMIT DO 
TARGET [LOOP_CNT + TARGET_BIAS] := 
SOURCE [LOOP_CNT + SOURCE BIAS]; 
END; { CASE } 
END; { Move Some Components } 
END; { MOVE Semantics > 

The interpretation of each of the met a -parameters is given below: 

component_type 

This meta-parameter permits the basic generality of each Move, 
such that the only restriction on component_type is that it 
is identical for source and target. 

source_packing 

This meta-parameter permits the source to be unpacked, PACKED, 
or CRUNCHED independent of target_packing. 

target_packing 

This meta-parameter permits the target to be unpacked, PACKED, 
or CRUNCHED independent of sourcejpacking. 

move_error 

This meta-parameter permits implementation flexibility, such that 
the method of signalling the error is not defined beyond that it is 
signaled. 

move_r_to_l_move_l_to_r 

This meta-parameter permits the description of both MoVe_R_to_L 
and MoVe_L_to_R in the procedure given above . The CASE on this 
meta- parameter selects the component movement semantics for each 
procedure. 



MOVE Procedure Example 
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MODULE MoveExample; 

IMPORT OtherModule; 

EXPORT 

PROCEDURE ExampleProc; 

IMPLEMENT 

TYPE 

IxTypel ■ 0. .20; 
IxType2 = -3-. Hi 

Schemal (L,H : IxType2) = 

ARRAY [L..H, IxTypel] OF ImportedType ; 
Schema2 (L,H : IxTypel) ■ 

CRUNCHED ARRAY [L. .H] OF ImportedType; 

Discrml = Schemal (0,15); 
Discrm2 = Schema2 (5,10); 

Arrayl = PACKED ARRAY [IxTypel] OF ImportedType; 
Array2 = ARRAY [IxType2, IxTypel] OF ImportedType; 

VAR 

DVarl : Discrml; 
DVar2 : Discrm2; 
AVarl : Arrayl; 
AVar2 : Array2; 

PROCEDURE ExampleProc; 
VAR 

ix : Integer; 

BEGIN 

Mo»e_L_to_R (10,DVarl,6,AVar2,0); 
FOR ix := TO 9 DO (equivalent FOR loop) 
AVar2 [ ix ] : = DVarl [ ix+6 ] ; 

MoVe_L_to_R (5,AVar2[5] ,-3,AVarl,-3) ; 
FOR ix := TO k DO (equivalent FOR loop) 
AVarl[ix-3] :■ AVar2[5,ix~3] ; 

Uaoe R_to_L (6 ,DVar2 , 5 , AVarl , 5) ; 

FOR ix := 5 D0WNT0 DO (equivalent FOR loop) 

AVarl [ ix+5 ] : = DVar2 [ ix+5 ] ; 
END; 

END. 



62 



XCall Mechanism 



7. XCall Mechanism 

EXtermely Flexible Procedure CALL Mechanism 

a. Background 

Some system software needs to call routines whose identity and 
parameter list structure are COMPLETELY UNKNOWN until the system is 
executing. The unknown structure of the parameter list makes the 
strong type checking of CALL/FCALL inadequate for this SMALL class of 
system software. The predefined procedure XCall was included in BCG 
MODCAL to support ONLY this small class of system software. The por- 
tability of XCall is limited by the requirement that the system 
programmer provide for the (machine dependent) structuring of the pa- 
rameter list. The use of this feature should be VERY limited. 

b. Definition 

The following procedure declaration describes the calling se- 
quence and semantics of the XCall predefined procedure. The defini- 
tion of a supporting predifined procedure, predefined types and a 
compiler option are described in a later section. Not all parameters 
or operations of XCall may be supported on all target machines (e.g. 
del_cnt for VISION), their use may be flagged. 

Simply XCall checks the given preconditions. Copies a parameter 
list from a buffer built by the system software into the "parameter- 
area" of the target machine (e.g. the stack for the HP3000). 
Invokes the routine denoted by the procedural variable paramenter. 
The invoked routine may or may not clear/delete part of the 
"parameter-area". When the invoked routine completes (a machine 
dependent) part of the "parameter-area" may be copied into a buffer. 
Finally the "parameter-area" is cleared/deleted and XCall completes. 
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PROCEDURE XCall 


■ ( 




proc var . 


NullProc ; 


ANYVAR in_buf 


SU; 


in_cnt 


ObjectSize; 


del cnt 


ObjectSize; 


ANYVAR out_buf 


SU; 


out cnt 

) 

OPTION 


• ObjectSize 




Inline 




Default Parm ( 




inbuf 


- NIL, 


in_cnt 


- 0, 




del_cnt 


- o, 




out_buf 


:= NIL, 


out cnt 


: = 0) 


• 
> 



BEGIN 

ASSERT (proc_var <> NIL , XCALL_err) ; 

ASSERT (in cnt >= (del cnt + out cnt) , XCALL_err) ; 

ASSERT ((in cnt ■ 0) OR (HaveOptVarParm(in_buf )) , XCALL_err) ; 

ASSERT ((out_cnt - 0) OR (HaveOptVarParm(out_buf )), XCALL__err) ; 

(COPY in_cnt SUs FROM in_buf INTO "PARAMETER-AREA") 

{INVOKE proc_var) 

(COPY out_cnt SUs FROM "PARAMETER-AREA" INTO out_buf) 

{CLEAR/DELETE in_cnt - del_cnt SUs FROM " PARAMETER -AREA" } 

END; 

c. Supporting Definitions 

The MdkeRoutine predefined procedure is intended to provide a 
mapping from a target machine dependent form to a target machine in- 
dependent (language encapulated) form for procedural variables. If 
the mapping can not made "proc var" is set to NIL. 
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PROCEDURE MakeRoutine ( 

VAR proc_var : NullProc; 
plabel_yal : PLabel 

) 

OPTION 
Inline 
Type_Coerce_Parms ( 

proc_var := 'Similar_Form'); 

BEGIN 

{MAP plabel_yal INTO proc_var} 

END; 

The following type PLabel is added to the foundation module for 
each target machine (operating system) . 



TYPE 

PLabel = -32768 . 
PLabel = -32768 . 
PLabel = Minlnt . 



-1; (*HP3000 - 
32767; (*HP3000 + 
Maxlnt; (*VISION*) 



CST ext.*) 
CST ext-*) 



The type NullProc is any user procedural type variable with no 
parameters. For example: 

TYPE 

NullProc = PROCEDURE; 

The XCALL_MACHINE compiler option denotes to the compiler and 
the system programmer which target machine's parameter passing con- 
ventions are used in any XCalls. This option must specify the same 
target machine name as the $TARGET_MACRTNE compiler option did. This 
option may appear anywhere between tokens. It must appear and must 
specify a value other than 'NONE' before any XCall is encountered. 
It should also be used to "bracket" any code used to build parameter 
lists. 



$XCALL_MACHINE 'NONE'$ 
$XCALL_MACHINE 'HP3000'$ 
$XCALL MACHINE 'VISION '$ 



{default} 



d. XCall Example (HP3000) 
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TYPE 
NoParms - PROCEDURE; 

VAR 

ij,k : INTEGER; 

buffer : ARRAY[1~3] OF INTEGER; 

FUNCTION Min_Int (parml,parm2 : INTEGER): INTEGER; 
EXTERNAL; 

BEGIN 

$XCall_MACHINE , HP3000 , $ 

buf f er[l] :- 0; {function return space} 

buf f er[2] :■ i; 

buff er[3] :» j; 

$PUSH,TYPE_COERCION 'REPRESENTATION'S 



XCall (NoParms(Aidr(Min_Int) ), 
buffer, 6, {pushed onto stack} 
4, {EXIT 4 from Min_Int} 

k, 2); {poped from stack} 

$POP,XCALL_MACHINE TMONE'S 
END; 
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8. Multiple Heaps NOT IMPLEMENTED 



However, routines can be written to manage MODCAL objects in a "heap -like" fashion, by 
manipulating offsets. 



/ \ _ 

/ w \ 

/ THE \ 
/ HEAP \ 



A . A _ 

/ \_/ \ / \J \ 

I other \ / other \ 

/ Heap #1 \ / Heap #2 \ 



A _ A _ 

I \J\ I \J \ 

I other / other \ 

/ Heap #3 \ / Heap #U \ 
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E - Standardized Modules 

1. Portability Foundation 

In order to assist the programmer in writing programs which will 
be portable between various machines, MODCAL must provide facilities for 
determining attributes of the targeted computer architecture. This 
section describes a set of predefined types, constants, and functions which 
will provide this function. These facilities are essentially a subset of 
the portability facilities found in Ada. 

The cornerstone of these facilities is the notion of a storage unit 
(SU) . A SU is the most useful addressable unit of storage on the tar- 
get machine. All memory-related features of MODCAL (e.g., pointers, off- 
sets, and objects) are defined in terms of SU's and many of the 
predefined functions work in terms of SU's. 

In MODCAL/VCF integer is the default size for arithmetic expressions. 
No expression will use Longint arithmetic unless a variable or constant of 
Longint is in the expression. Thus it possible to have arith- 
metic traps on expressions involving only the integer type. Longint will 
only be supported on Vision. The assignment compatibility rules which 
apply to type integer also apply to type short int and longint. 

Note: Longint constants MaxLonglnt or MinLonglnt or any constant 
which needs more than 32 bits of storage WILL NOT be available on the 
MODCAL/VCF cross compiler. 

Floating point is not generally required for systems program- 
ming and so will not be addressed in this proposal. 

Using the Sizeof function instead of absolute, hardcoded constants 
will aid in portability, since the values will automatically be adjusted 
when a program is recompiled for a different target machine. In 
addition to Sizeof, MODCAL/3000 and MODCAL/VCF have: 

Bitsizeof{t) Gives the minimum number of bits required to 
represent a variable of type t. 

Bitsizeof(tl t t2, ... ,tn) Gives the minimum number of bits 
required to represent a variable of type tl with tag field values t2, ... , 
tn. 

BitSizeof (si, s2, ... ,sn) Gives the minimum number of bits required 
to represent a variable of the discriminated schema type select from the 
schema array si with discriminate values s2,...,sn. 

SO sizeof (t) 

SU sizeof (tl, t2, ... ,tn) 
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SUsizeof (si, s2, . .., sn) 



SUsizeof is similar to Bit'sizeof but returns the storage size in SU 
units instead of bits. 

The following are the predefined types and constants. The exact 
values of these types and constants are indicated below: 

a. HP3000 Foundation 

CONST 

MachineName = 'HP3000'; 
Minint = -21U7U836U8; (* -2**31 *) 
Maxint = 21W36U7; (* (2**3D -1 *) 

MaxObjectSize = 32760; (* maximum number of SUs in a HP 3000 

object *) 

TYPE 

SU - -32768.. 32767; (* A type requiring a SU of space *) 

(* 16 bits on HP 3000 *) 
PointSU ■ "SU; 
OffsetSU = OFFSET TO SU; 
ObjectSize = 0. .MaxObjectSize; 
ObjectDelta = -MaxObjectSize. .MaxObjectSize; 

Shortlnt = -32768.. 32767; (* 16 bit, 2's complement integer *) 
Integer = Minint .. Maxint; 

Object id = Short int; 



b. Vision Foundation 

CONST 

MachineName = 'Vision' ; 

Minint = -21U7U836U8; (* -2**31 *) 

Maxint = 21U7U836U7; (* (2**31 )-l *) 

MaxObjectSize = Maxint; (* maximum number of SUs in a Vision 

object *) 
{the following 2 constants are not implemented in the cross compiler) 

Maxlongint = 922337203685^775807; (* (2**63) -1 Vision only*) 

Minlongint = -922337203685^775808; (* -(2**63) Vision only *) 

TYPE 

SU = 0..255; (* A type requiring a SU of space *) 

(* 8 bits on VCF *) 
PointSU = "SU; 
OffsetSU = OFFSET TO SU; 
ObjectSize = 0. .MaxObjectSize; 
ObjectDelta = -MaxObjectSize. .MaxObjectSize; 

Shortlnt = -32768. .32767; (* 16 bit, 2's complement integer *) 

Integer = Minint .. Maxint; 

Longlnt = -Minlongint .. Max'longint; (* VCF machine only *) 
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Object id = Integer; 
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2. Assembly Language 

A set of predefined procedures will be provided, 
which when seen by the compiler, will emit instructions that are 
not normally generated, such as SINC, and DISP on the HP 3000, 
and PROBE on VCF. This set of predefined procedures is in the 
process of being determined. The list given here is for Version 
5 of the Vision emulator only. 

The normal method for accessing assembly language is to 
compile the code into a SPL procedure on the HP 3000, or using 
the assembler on Vision. 



a. HP3000 Predefined Procedures 



TYPE 



Word = Shortlnt; { SizeOf 
PAC = Any Packed Array of Char 
or String 



= 2 } 



Function 

Function 

Function 

Function 

Procedure 

Procedure 

Procedure 



Function 



Function 



Function 



GetDl : Word; 

GetQ : Word; 

GetS : Word; 

GetStatus : Word; 

PutQ (Q_val : Word); {NOT IMPLEMENTED) 

PutStatus (Status_val: Word); 

MoOeBytesWhile (var Source, 

Target: PAC; 
Alpha, Numeric, UpShift: 
var Position: Word); 
Scar&ftiile (var Source: PAC; 

TestChar, TermChar: Char; 
var Position: Word) : Boolean; 
Scanffntil (var Source: PAC; 

TestChar, TermChar: Char; 
var Position: Word) : Boolean; 
CmpBytes ( Len: Word; 
var Source, 

Target: PAC 
) : Word; 



Boolean; 



b. Vision Predefined Procedures 



TYPE 



Byte = (opl, op2, op3); { SizeOf - 1 ) 
ByteU = Integer; < SizeOf = k } 
Byte8 = Longlnt; { SizeOf ■ 8 ) 



Procedure Break; 
Procedure CIS ( 



Channel: Byte; 
Status : Byte 
var ConditionCode: Byte); 
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Procedure CmpC ( Length: ByteU; 

StrlPtr: Byte8; 
Str2Ptr: Byte8; 
var Index: ByteU; 
var Result: Bytel); 
Procedure CvLATVA ( Operand: Byte; 

var GSVA: Byte8); 
Procedure CvVAXPP ( GSVA: Byte8; 

var Physicalpage: ByteU); 
Procedure Disable; 
Procedure Disp; 

Procedure Down (var Semaphore: ByteU); 
Procedure Enable; 
Function GetQ: Byte8; 
Procedure HaltJLnst; 
Procedure Bask ( GSVA: Byte8; 

var Hashlndex: ByteU); 
Procedure IExit; 

Procedure Interrupt (var OldlntVal: Byte); 
Procedure IfC; 
Procedure Idle; 
Procedure IStiitch; 
Procedure Launch (TCRA: Byte8; 

TCBVA: Byte8); 
Procedure MoVeFSp4 ( Selector: Byte; 

var Destination: ByteU) ; 
Procedure MoveFSp8 ( Selector: Byte; 

var Destination: Byte8); 
Procedure MoveSemz ( Operand: ByteU; 

var Result: ByteU); 
Procedure MoveTSp4 (Selector: Byte; 

Source: ByteU); 
Procedure MoVeTSp8 (Selector: Byte; 

Source: Byte8); 
Procedure PDDel (Physpage: ByteU); 
Procedure PDIns (Physpage: ByteU); 
Function Probe (Ring: Byte; Access: Byte; 
Addres s : Byte8 ; 
Lenght: ByteU): Boolean; 
Procedure PsDb; 
Procedure PsEb; 
Procedure PurgelB; 
Procedure PurgeTLB; 
Procedure PCI; 

Procedure RDP ( Channel: Byte; 
var Data: ???? 
var Length: Byte; 
var Result: Byte ); 
Procedure Restore _Registers (RegPtr: Byte8); 
Procedure RIS ( Channel: Byte; 
var Status: Byte; 
var Result: Byte); 
Procedure RSwitch; 
Procedure Save_Registers (var RegPtr: Byte8); 
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Procedure SetIRT (Channel: Byte; 

Intr_Pri_Level: Byte; 
ParroT ByteU ); 
Procedure SetQ_Bxit (NewQ: Byte8); 
Procedure SetQ IExit (NewQ: Byte8); 
Procedure SIS J Channel: Byte; 

Status: Byte; 
var Result: byte); 
Procedure StartIO_Inst (Subchannel: ByteU; 

ChannelProg: Byte8) ; 
Procedure Stop\ 
Procedure Saitohi 
Function TestA : Boolean; 
Function TestB : Boolean; 

Function TestDotin (var Semaphore: ByteU): Boolean; 
Function TestOv : Boolean; 
Function TestRef (GVSP: Byte8) : Boolean; 
Function TestSemz (var Operand: ByteU; 

Result: ByteU) : Boolean; 
Procedure Up (var Semaphore: ByteU); 
Procedure Vsimln ( ReadCount: ByteU; 

var ActualCount: ByteU; 
BufferPtr: Byte8); 
Procedure VsinOut (WriteCount: ByteU; 

BufferPtr: Byte8); 
Procedure WDP ( Channel: Byte; 

Data: ???? 
var Lenght: Byte); 

The following Version 3 emulator predefined procedures are 
deleted from the ERS and the compiler: 

IntOff 

ReSetlnt 

IExit 

CheckA 

CheckB 

EditTBL 

EditIB 

AsReset 

GrpZero 

CvLAtVP 

CvVPtPP 
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Appendix A: Options and Direct ives 



1. PROCEDURE/FUNCTION DEFINITION OPTIONS 

Definition options specify optional attributes of 
a procedure or function (e.g. method of envoking it) 
as part of the routine head; the form is: 

PROCEDURE proc_name (parm name s type name) 
OPTION INLINE; 

BEGIN 

END; 

the syntax is: 

<rout ine_heading > 

-> <procedure_heading> <defn_options> ? 
-> <function_heading> <defn_options> ? 

<defn_options> 

-> 'OPTION' <defn_opt> + 

<defn_opt> 

-> <option_id> ( <option_spec_list> | 

<option_spec_yalue> ) ? 

<option_id> 

-> <identifier> 

<option_spec_list> 

-> '(' <opt_spec_assoc> LIST ',' *)' 

<opt_spec_assoc> 

-> <spec_parm_id> *:=' <expression> 

<spec_parm_id> 

-> <identifier> 

<opt ion_spec_value > 
-> < integer > 



Pascal Definition Options 
not a feature of Pascal 
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HODCAL Definition Options and Restrictions 
(which <option_id>'s can he used together) 



MODCAL 


Parameter /Calling 


Optional 


Linker 






Keyword 


Convention 


Parameters 


Binding 


Other 


OPTION 






Unresolved 


<}; 
<3); 


OPTION 




Def ault_Parms { 1 ) 




<); 


OPTION 




Def ault_Parms (1 ) 


Unresolved 


<3); 




OPTION 


Inline 






<U)i 




OPTION 


Inline 


Def ault_Parms {1 ) 




W\ 




OPTION 


Gateway 






<5>; 




OPTION 


Gateway 




Unresolved 


(5); 




OPTION 


Gateway 


Def ault_Parms {1 ) 




(5); 




OPTION 


Gateway 


Def ault_Parms {1 ) 


Unresolved 


(5); 




OPTION 


Extens ihle_Gateway { 2 } 






<5)' 




OPTION 


Extens ible ^Gateway { 2 ) 




Unresolved 


(5) 




OPTION 


Extens ible JSateway { 2 ) 


Def ault_Parms {1 ) 




<5) 




OPTION 


Extens ible_Gateway { 2 ) 


Def ault_Parms {1 ) 


Unresolved 


(5) 




OPTION 


Interrupt_Parms { 1 ) 






(3,6); 


OPTION 


Interrupt_Parms { 1 ) 




Unresolved 


(3,6); 


U> 


<opt defn> -> <option 


i_id> <option_spec_ 


_list> 




(2) 


<opt_defn> -> <optior 


l id> <option_spec_ 


value > ? 




<3) 


routine is declared on 


level 1 






<H) 


routine is non-recursive 






<5) 


routine is declared in 


EXPORT part 






(6) 


PROCEDURES only 











note : Uncheckable_ANYVAR can be used with any other 
definition option 



a. OPTION Inline 

Definition option Inline denotes a procedure or function that 
will he expanded inline wherever it is invoked. This macro-like ex- 
pansion removes most procedure call overhead and increases the amount 
of object code generated. This expansion is performed so as to 
retain "Call-By-Reference" where a simple macro expansion would 
result in "Call-By-Name" (i.e. variable parameters work the same with 
OPTION Inline) . Inline procedures or functions cannot invoke themsel- 
ves or any other mutually recursive inline procedures or functions. 
If an inline procedure or function contains any non-inline procedures or functions 
$Private_Proc Of f $ MUST BE specified for them. 

b. OPTION Gateway 

Definition option Gateway denotes a procedure or function that 
is a gateway into the MODCAL environment. That is, Gateway 
procedures or functions are MODCAL procedures or functions that must 
support the system defined calling conventions. In other words, 
Gateway is used to denote intrinsics that can he called from any 
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programming language. This definition option can be specified only 
on level one procedures or functions. 

c. OPTION Extensible_Gateway 

Definition option Extensible_Gateway denotes a procedure or 
function that is 'a gateway into the MODCAL environment and that has 
an extensible parameter list. That is the parameter list has a fixed 
number of non-extension parameters and any number of optional exten- 
sion parameters. The integer value part of this definition option 
specifies the number of non-extension parameters. This definition 
option can be specified only on level one procedures or functions, 
(see HaveExtension function) 

NOTE: This option will be accepted by MODCAL/3000 but it will have 
several special properties. The specification of extension parameters is not supported, 
due to 3000 parameter stacking conventions. Code generated for one of these 
Extensible_Gateway routines expects an EXTERNAL SPL VARIABLE (in 
Pascal/MODCAL) style bit map. This implies that they should be specified as OPTION 
VARIABLE EXTERNAL (in SPL) to BUILDINT.PUBSYS. The bit map is checked just 
before any data references. Any omitted optional parameters are supplied (see Option 

Default Parms) and any omitted required parameter causes an Escape. This checking 

delay permits the first statement in a routine to be a TRY, so missing parameter escapes 
can be handled. 



d. OPTION Interrupt_Parms 

Definition option Interrupt_Parms denotes a procedure that has 
its parameter list allocated AS SPECIFIED BY the <option_spec_list> 
part of this option. The <spec_parm_id> denotes the formal parameter 
and the constant <expression> denotes the "activation base relative" 
offset (on VCF the Q base register relative SU, byte, offset) of that 
parameter. This option can be specified only on level one procedures. 
These procedure have their local variables allocated so as to not 
overlay- any parameters. The consistency of the parameter offsets IS 
NOT CHECKED. No procedure defined with the option may appear in any 
procedure statement. No variable of a procedural type defined with 
this option may appear in any Call. Only the standard activation 
record or stack marker is deleted when this procedure exits. 

NOTE: FORM OF PROCEDURE EXIT IS SUBJECT TO REVISION!!! 

NOTE: MODCAL/3000 WILL TREAT THIS OPTION AS AN NO OP! ! ! 

e. OPTION DefaultJParms 

Definition option Default_Parms denotes which parameters may be 
omitted in any actual parameter list for this procedure or function. 
This is specified by the parameter name appearing as the 
<specjparm_id> in the <option_spec_list> syntax, with an assignment 
compatible~constant <expression>. If the actual parameter is omitted 
the compiler suppilies the default value for the formal parameter 
corresponding to the position of the omitted actual parameter. This 
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requires that the compiler supply all the parameters defined in the 
formal parameter list for every call. Thus any formal parameter that 
does not appear as a <spec_parm_id> in this definition option is 
required and can not be omitted from ANY actual parameter list. The 
only default value permitted for a variable (VAR) , any variable 
(ANYVAR), procedure, or function parameter is a SPECIAL CASE USE of 
NIL. (see HaoeOptVarParm function) 

f . OPTION Unresolved 

Definition option Unresolved denotes a procedure or function 
that is left unresolved by both the segmenter/linker and the loader. 
The resolution of the symbolic name to its reference part is delayed 
until the procedure or function is used (e.g. LOADPROC (); PCAL / 
CALLPROC (); CALLV) . The suggested way to use this kind of procedure 
or function is to use Addr to determine if it can be resolved (NIL 
will be returned if it is not). This definition option can be 
specified only on level one procedures or functions. 



g. OPTION Uncheckable_ANYVAR NOT IMPLEMENTED 



Defintion option Uncheckable ANYVAR indicates the no "phantom" size-of pa- 
rameter is to be created for the ANYVAR parameters in the formal parameter list. It 

is an error to specify option Uncheckable ANYVAR if there are no ANYVAR formal 

parameters. It is not possible to perform checking of ANYVAR parameter accesses if 
this option is specified. The use of this definition option greatly increases the danger of 
undetected errors in the use of ANYVAR parameters, (see Section D) 



h. HaveExtension and HaoeOptVarParm Functions 

The predefined boolean function HaveExtension indicates for a 
formal parameter name of the surrounding scope whether an actual ex- 
tension parameter was supplied, either explicitly or by default 
(TRUE) or the formal parameter appears after the last supplied actual 
parameter in the parameter list (FALSE). If the formal parameter 
name is not an extension parameter a compile time error is issued. 

The predefined boolean function HaoeOptVarParm indicates for a 
formal parameter name of the surrounding scope whether an actual pa- 
rameter was supplied (TRUE) or it was defaulted to NIL (FALSE). If 
the formal parameter name is not an optional variable, any variable, 
procedure, or function parameter a compile time error is issued. 
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i. Definition Option Example 
$TARGET_MACHINE * VISION' $ 

PROCEDURE UseNewFuncs ( 
VAR Parml : Typel; 
VAR Parm2 : Type2 ) 
OPTION 

Extensible_Gateway 1 
Default_Panns ( 
Parml := NIL, 
Parm2 := NIL ); 
BEGIN 

IF HaoeExtension (Parm2) THEN 
IF HaoeOptVarParm (Parml) THEN 
IF HeafeOptVarParm (Parm2) THEN 

4* CALL 1 *) 
ELSE 

(» CALL 3 *) 
ELSE 

IF HaOeOptVc&Parm (Parm2) THEN 

(* CALL 2 *) 
ELSE 

(• CALL U *)/ 
ELSE 

IF HaoeOptVarParm (Parml) THEN 
(* CALL 5 *)' ■ 

Assert (NOT HaVeOptVarParm (Parm2), 3) 
ELSE 

(* CALL 6 *) 

Assert (NOT HaoeOptVarParm (Parm2), U); 
END; 

{ It is assumed that the following calls to "UseNewFuncs" 
were compiled AFTER its parameter list was extended by 
the addition of "Parm2" } 

(* CALL 1 *) UseNewFuncs (Varl,Var2); 

(* CALL 2 *) UseNewFuncs (,Var2); 

(• CALL 3 *) UseNewFuncs (Varl) ; 

(* CALL k *) UseNewFuncs (); 

( It is assumed that the following calls to "UseNewFuncs" 
were compiled BEFORE its parameter list was extended by 
the addition of "Parm2" } 
(* CALL 5 *) UseNewFuncs (Varl); 
(* CALL 6 *) UseNewFuncs (); 
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2. PROCEDURE/FUNCTION DIRECTIVES 

Pascal Procedure/Function Directives 
"EXTERNAL 

external SPL 3000 only 

external SPL VARIABLE 3000 only 

external FORTRAN 

external COBOL 
•FORWARD 
"INTRINSIC 
MODCAL Procedure /Function Directives 
"EXTERNAL 

external ASSEMBLER Vision only NOT IMPLEMENTED 



a. External 

Directive External indicates that the procedure or function will 
be compiled/as sembled by another language processor (default is 
Pascal). The MODCAL language processor assumes that the procedure or 
function will use the system defined calling conventions. 

NOT IMPLEMENTED 



1 


| EXTERNAL 


1 


| : any : SPL : ASSEMBLER 


| Gateway 


| yes | Error | Error | Error 


| Extens ible_Gateway 


| yes | Error | Error | Error 


(Unresolved 


1 yes | yes | yes | yes 


| Inline 


| Error | Error | Error | some day? 


| Default Parms 


1 yes 1 yes | yes | yes 


| Interrupt Parms 


| yes | Error | yes | yes 


lUncheckable ANYVAR 


1 yes | yes | yes | yes 



{ any IN [COBOL, FORTRAN, SPL VARIABLE] } 



b. Forward 

Directive Forward indicates that the procedure or function body 
occurs somewhere later in the compilation unit. This directive per- 
mits mutually refering procedures and functions. 
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MOT IMPLEMENTED 















1 


1 


FORWARD 


1 




| Gateway 

| Ext ens ible_Gat eway 

| Unresolved 

j Inline 

| Def ault_Parms 

j Interrupt Parms 

| Uncheckable_ANYVAR 




yes 
yes 
Error 
Error 
yes 
yes 
yes 




Intrinsic 











Directive Intrinsic indicates that the procedure or function 
declaration is contained in the system intrinsic file. 



NOT IMPLEMENTED 





1 1 


INTRINSIC | 


| Gateway 


Error | 


| Extensible Gateway | 


Error I 


| Unresolved | 


yes | 


| Inline 


Error I 


| Default Parms | 


yes | 


(interrupt Parms | 


Error | 


|Uncheckable_ANYVAR j 


yes | 
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3. COMPILER OPTIONS 

Compiler options specify compilation controls 

(e.g. features allowed, disabling run-time checking); 

the form is: 

$STANDARD_LEVEL 'BCG_MODCAL'$ 
PROGRAM prog_name; 
PROCEDURE~pr o c_name 
$EXEC_PRIVILEGE 0$ 
(parm_name : type_name); 



$BEGIN_CRANGE '001601'$ 
$END CHANGE '001601' ,PAGE$ 



Pascal Compiler Options 
Compilation Unit Options 
•COPYRIGHT 

copyright '* 
•EXTERNAL 
•GLOBAL 
*HEAP_COMPACT 

heap_compact ON 

heap_compact OFF 
•HEAPJDISPOSE 

heap_dispose ON 

heap_dispose OFF 
•SET 

set »• 
•SUBPROGRAM 

subprogram 

subprogram *' 
•USLINIT 

Routine Head Options 
•ALIAS 

alias •• 
SYMDEBUG 

symdebug ON 
symdebug OFF 

Any Token Options, Deferred 
*CHECK_ACTUAL_PARM 

check_actualj?arm 0..3 
*CHECK_FORMAL_PARM 

check_formal_parm 0..3 
•CODE 

code ON 

code OFF 
*C0DE_OFFSETS 

code offsets ON 
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code offsets OFF 
*LINES 

lines 20..MAXINT 
*LIST_CODE 

list code ON 

list~code OFF 
•PRIVATE~PROC 

privatejproc ON 

privatejproc OFF 
•SEGMENT 

segment *' 
•SPLINTR 

splintr " 
STATS 

stats ON 

stats OFF 
•TABLES 

tables ON 

tables OFF 
•TITLE 

title " 
•XREF 

xref ON 

xref OFF 

Any Token Options, Immediate 
•ANSI 

ansi ON 

ansi OFF 
*ASSERT_HALT 

assert_halt ON 

assert halt OFF 
•ELSE 

else 
•ENDIF 

endif « 
•FONT 

font • * 
•IF 

if " 
•INCLUDE 

include »• 
•LIST 

list ON 

list OFF 
•PAGE 
*PARTIAL_EVAL 

partial_eval ON 

partial"eval OFF 
•RANGE 

range ON 

range OFF 
•SKIP_TEXT 

skipjtext ON 
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skipjtext OFF 

*STANDARD_LEVEL 

standard_level 'ANSI* 
standard_level 'HP STANDARD ' 
standard_level 'HP3000' 

•WIDTH 

width 10.. 128 

HODCAL Compiler Options 
Compilation Unit Options 
*ACD_VERSION 

acd version 3.. 5 
CRUNCH~PACKING 

crunchjpacking ON 

crunch packing OFF 
MULTIPLE_HEAPS 

multiple_heaps ON 

multiple_heaps OFF 
INITIAL_EXEC_PROBE 

initial_exec_probe O..MAXINT 
OBJECTDEFINITION 

object_definition ON 

object~def inition OFF 
0PTI0N_LOGGING 

option_logging ON 

option_logging OFF 
SCHEMA_ARRAYS 

schema_arrays ON 

schema_arrays OFF 
*TARGET_MACRTNE 

target_raachine 'HP3000 ' 

targetjnachine 'VISION* 

Routine Head Options 
*CALL_PRIVILEGE 

call_jprivilige 0. .3 

DYNAMIC_SIDE_EFFECTS_OK 

dynamic_side_effects_ok ON 
dynamic~side~effects ok OFF 
*EXEC_PRIVILEGE 

execjprivilige 0..3 

PROBE_RES0LUTI0N (see DEBUG) 
probe_resolution 'NO PROBES ' 
probe_resolut ion ' ROUTINE ' 
probe_resolution 'DECISION_PATH' 
probe_resolution 'STATEMENT' 
probe_resolution 'OPERATION' 

STATIC_SIDEJEFFECTS_OK 

static_side_effects_ok ON 
static~side_effects_ok OFF 

UNDEFINED_VAR_CHECKING 

undef ined_var_checking ON 
undef ined_var_checking OFF 



83 



Appendices 



Any Token Options, Deferred 

BEGIN_CHANGE 

begin_change " 

CHANGE_INFO_WIDTH 

change info_width U..30 

END_CHANGE 

end change * * 

OBJECT^SELECTION 

object_selection ON 
object selection OFF 

PROBE_INSERTION 

probe_insertion ON 
probe_insertion OFF 

SEARCH 
search ' ' 

TABULATE_CHANGE_INFO 

tabulate_change_info ON 
tabulate change info OFF 
*TYPE_COERCION 

type_coercion *NONE' 
type coercion 'STRUCTURAL' 
type'coercion 'REPRESENTATION' 
type coercion 'STORAGE' 
type~coercion 'NONCOMPATIBLE' 

Any Token Options, Immediate 
INDEX_CHECKING 

index checking ON 

index_checking OFF 
OPEN_SCOPE_CHECKING 

open_scope_che eking ON 

open scope_checking OFF 
*POP 
*PUSH 
REFERENCE_CHECKING 

reference_checking ON 

reference_checking OFF 
*STANDARD_LEVEL 

standard_level 'HP_MODCAL' 

standard level 'BCG MODCAL' 
SUBRANGE_CHECKING 

subrange_che eking ON 

subrange_checking OFF 
SCHEMA_CHECKING 

scheraa_checking ON 

schema_che eking OFF 
TAG_CHECKING 

tag_checking ON 

tag checking OFF 
UNDEFINED_PARM_CHECKING 

undef ined_parm_checking ON 

undef ined_parm_checking OFF 
*XCALL_MACHINE 

xcall machine 'NONE' 
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xcalljnachine *HP3000' 
xcall machine 'VISION' 



(*) denotes feature operational in current release MODCAL/3000 
a. ADC Version 



This compiler option is used to inform the compiler which version of the Vision ACD 
is be used, so that the correct set of assembly instructions is made availible. 



b. Alias 

This compiler option substitutes an alias as an external name 
for a procedure or function. See the Pascal/3000 reference manual. 

c. Ansi 

This compiler option causes all non ANSI Standard Pascal fea- 
tures to be flagged. The default setting is OFF. See the Pascal/3000 
reference manual. 

d. AssertJHalt 

This compiler option specifies that when an assertion fails, the 
program will terminate. The default setting is OFF. See the 
Pascal/3000 reference manual. 

e. Begin_Change NOT IMPLEMENTED 



This compiler option specifies the identifying string to be made the most recent in the change 
history of the source. The change history is displayed to the right of the source line with the 
most resent change closest to the source. See Tabulate_Change Info option. 



f. Call Privilege 



This compiler option specifies the least privilege (largest numerical value) that any 
procedure or function may be executing at when it invokes this procedure or function. 
This compiler option provides the functionality of OPTION UNCALLABLE in 
SPL/3000 (HP3000: -> Uncallable, 1 -> Callable). Default is least privilege on target 
machine (HP3000: 1, Vision: 3). 



g. Change_Info_Width NOT IMPLEMENTED 



This compiler option specifies the number of characters displayed in each column of the 
change history. Default is 8. 
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h. Check_Actual_Parm 

This compiler option specifies the level of checking the 
Segmenter will perform when MODCAL calls a procedure or function. 
The default setting is level 3- See the Pascal/3000 reference 
manual. 

i. Check_Formal_Parm 

This compiler option specifies the level of checking the 
Segmenter will perform when a procedure or function is called. The 
default setting is level 3. See the Pascal/3000 reference manual. 

j. Code 

This compiler option casues object code to be generated at the 
end of each procedure, function or outer block. The default setting 
is on. See the Pascal/3000 reference manual. 

k. Code_Offsets 

This compiler option causes a table of P locations to be printed 
for each statement. The default setting is OFF. See the Pascal/3000 
reference manual. 

1. Copyright 

This compiler option inserts a copyright notice and the 
specified name in the USL file. See the Pascal/3000 reference 
manual. 

m. Crunch_Packing NOT IMPLEMENTED 



Crunch_Packing ON tells the compiler that the Crunch Packing feature of MODCAL will be 
used in the source. OFF tells the compiler that CRUNCHED will not be used; CRUNCHED will then 
be flagged as an error. Default is ON. 



n. pynamic_Side_Effects_Ok NOT IMPLEMENTED 



This compiler option turns ON and OFF the ability to make modifications to the variables 
referenced by reference types. Default is ON. 



o. Else 



This compiler option is used in conditional compilation. If the corresponding $IF ex- 
pression is FALSE* then the source between the $ELSE and the corresponding $ENDIF 
will be compiled. 
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p. Endlf 

This compiler option is used in conditional compilation. $ENDIF signals the end of a 
$IF block or a $ELSE block. 

q. End_Change NOT IMPLEMENTED 



This compiler option specifies the (previously defined) identifying string that is to be removed 
from the change history. If the identifying string appear more than once the most recent is 
removed. 



r. Exec Privilege 



This compiler option specifies the privilege at which this procedure or function will 
execute. This compiler option provides the functionality of OPTION PRIVILEGED in 
SPL/3000 (HP3000: -> Priv-Mode, 1 -> User-Mode). Default is least privilege on tar- 
get machine (HP3000: 1, Vision: 3). 



s. External 

This compiler, option is used with the option Global to permit 
separate compilation of procedures and functions. See Pascal/3000 
reference manual. 

t. Font 



This compiler option is used to change the primary and alternate character set used 
in the listing file (for use with 2680A laser printer) The string parameter is composed of 
2 integers separated by a comma, the first is the number of the new primary set, and 
the second is the number of the new secondary set. Note: the switch between the charac- 
ter set can be done only within comments. 



u. Global 

This compiler option is used with the option External to permit 
separate compilation of procedures and functions. See Pascal/3000 
reference manual. 

v. Heap_Compact 

This compiler option causes free areas in the heap to be com- 
bined. The default setting is OFF. See the Pascal/3000 reference 
manual . 
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w. Heap_Dispose 

This compiler option permits disposed areas in the heap to be 
reallocated. The default setting is OFF. See the Pascal/3000 
reference manual. 

x. If 



This compiler option is used in conditional compilation. If the expression in the 
string following the $IF evaluates to the logical value TRUE, then the source between 
the $IF and the corresponding SENDIF or SELSE will be compiled. If the expression is 
FALSE, then the source will be skipped. The expression may include the AND, OR, and 
NOT operators and parenthesis. $IF may be nested to a depth of 16. 



y. Include 

This compiler option permits the inclusion of another file which 
the compiler will process as source code. See the Pascal/3000 
reference manual. 

z. Index_Checking NOT IMPLEMENTED 

This compiler option turns ON and OFF the generation of checking 
code for array indexing operations. Default is ON. 

aa. Initial Exec Probe NOT IMPLEMENTED 



Not yet fully defined. 



ab. Lines 

This compiler option specifies the number of lines that will ap- 
pear on a single page of the listing. The default setting is 55. See 
the Pascal/3000 reference manual. 

ac. List 

This compiler option turns ON and OFF the compiler's listing. 
The default value is ON. See the Pascal/3000 reference manual. 

ad. List_Code 

This compiler option causes a mnemonic listing of the object 
code generated to appear at the end of each procedure, function, or 
outer block. The default setting is OFF. See the Pascal/3000 
reference manual. 
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ae. MultipleJHeaps KOT IMPLEMENTED 



Multiple_Heaps ON tells the compiler that the Multiple Heap feature of MODCAL will be used in 
the source. OFF tells the compiler that Multiple Heaps will not be used; any use of multiple heap 
features will then be flagged as an error. Default is OFF. Multiple heaps will not be available initial- 
ly. 



af. Object_Definition NOT IMPLEMENTED 



Object_Definition ON tells the compiler that Object features will be used in the source. OFF 
tells the compiler that Objects will not be used; any use of object features will then be flagged as 
an error. Default is ON. 



ag. Object_Selection (will be implemented) 

This compiler option turns ON and OFF special code generation to 
optimize the access of the object most recently selected in a 
WITHOBJECT statement (e.g. on HP3000 calls to ExchangeDB) . Default 
is ON. 

ah. Open_Scope_Checking NOT IMPLEMENTED 



This compiler option turns ON and OFF generation of checking code for open scope checking. 
The default value is ON. 



ai. Option Logging NOT IMPLEMENTED 



This compiler option turns ON and OFF the generation of a statement by statement log file of 
the compiler options in effect. The default setting is ON. 



aj. Page 

This compiler option causes the compiler listing to a line 
printer to perform a page eject and start a new page. See the 
Pascal/3000 reference manual. 

ak. Partial_Eval 

This compiler option controls the way conditional (BOOLEAN) ex- 
pressions are evaluated. Default is ON. See the Pascal/3000 reference 
manual. 

al. Pop 

This compiler option restores the compile option to the state before the last Push. 
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1. Compiler Options Unaffected by Pop 

ACD_Version 
Alias 

Call__Privilege 
Copyright 

Exec Privilege 

External 

Font 

Global 

Include 

Page 

Profile_Cnt 

Push 

Segment 

Skip_Text 

Splintr 

Target Machine 

Title 



am. Private Proc 



This compiler option is used to make (ON) nested procedures and functions (level > 1) 
private to the RBM containing the surrounding level 1. If it is OFF each procedure or 
function is placed in a separate RBM, and must have a name unique at 15 characters. 
Default is ON. See the Pascal/3000 reference manual. 



an. Probe Insertion SOT IMPLEMENTED 



This compiler option turns ON and OFF the generation of software probes without affecting 
their syntactic resolution. Default is OFF. This option is set ON any time the Probe_Resolution 
option is specified. 



ao. Probe Resolution NOT IMPLEMENTED 



This compiler option specifies the syntax unit resolution of software probes inserted into the 
code generated. Default is that no probes are inserted. 



ap. Push 

This compiler option saves the current setting of options in an option set. No options 
are changed. 
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L Compiler Options Unaffected by Push 

ACD Version 

Alias 

Call_Privilege 

Copyright 

Exec Privilege 

External 

Font 

Global 

Include 

Page 

Pop 

Profile_Cnt 

Segment 

Skip_Text 

Splintr 

Target Machine 

Title 



aq. Range 

This compiler option causes range checking code to be generated. 
The default value is ON. See the Pascal/3000 reference manual. 



1. Compiler Options Implied by SRange ON$ 

$Index_Checking ON$ 

SRaference Checking ONS 

SSubrange Checking ON$ 

2. Compiler Options Implied by SRange OFF$ 

$Index_Checking OFF$ 

$Raference_Checking OFF$ 
$Subrange_Checking OFF$ 

$Open_Scope_Checking OFF$ 
$Schema_Checking OFFS 

$Tag_Checking OFFS 

$Undefined_Parm_Checking OFFS 

ar. Reference_Checking (will be implemented) 

This compiler option turns ON and OFF generation of checking 
code for references, i.e. pointer and object, offsets. The default 
value is ON. 
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as. Schema Arrays NOT IMPLEMENTED 



Schema_Arrays ON tells the compiler that Schema Array features will be used in the source. 
OFF tells the compiler that Schema Arrays will not be used; any use of schema array features will 
then be flagged as an error. Default is OFF. 



at. Schema Checking SOT IMPLEMENTED 



This compiler option turns ON and OFF generation of checking code for schema arrays. The 
default value is ON. 



au. Search NOT IMPLEMENTED 



The string literal parameter for Search names external libraries to be searched when satisfy- 
ing import lists. The libraries are searched in the order listed in the literal. This option overrides 
all prior Search options. Exactly how Search works is implementation defined. It has not yet 
been defined for MODCAL/VCF or MODCAL/3000. 



av. Segment 

This compiler option specifies the name for the current segment. 
The default segment name is Seg'. See the Pascal/3000 reference 
manual. 

aw. Set 



This compiler option is used in conditional compilation. $SET specifies all identifiers 
to be used as flags in the conditional compilation of the soucre. (See $IF.) The string 
which follows the $SET option contains a list consisting of an identifier, an '=', and the 
value of the identifier, either TRUE or FALSE. Each element is separated by a comma. 
(e.g. $SET 'Red=TRUE,Blue=FALSE'$ ) 



ax. SkipJText 

This compiler option causes the compiler to ignore all sub- 
sequent source code, including any compiler options, until SkipJText 
is turned OFF. See the Pascal/3000 reference manual. 

ay. Splint r 

This compiler option specifies which SPL intrinsic file to 
search for a procedure or function declared with the INTRINSIC direc- 
tive. The default file is Splintr.pub.sys. See the Pascal/3000 
reference manual. 
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az. Standard Level 



This compiler option specifies which syntax and semantics to ac- 
cept. If the source code contains a feature which is not in the cur- 
rent langage level, the compiler will issue a warning. See the 
Pascal/3000 reference manual. 

ha. Static_SideJEffects_Ok NOT IMPLEMENTED 

This compiler option turns ON and OFF the ability to make modifications to nonlocal variables. 
Default is ON. 



bb. Stats NOT IMPLEMENTED 

This compiler option produces statistical information about the 
compilation. The default setting is OFF. 

be. Syradebug NOT IMPLEMENTED 

This compiler option inserts symbolic debugging information into 
the object code. The default setting is OFF. 

bd. Subprogram 

This compiler option permits compilation of a subset of level 1 
procedures or functions. 

be. Subrange_Checking NOT IMPLEMENTED 

This compiler option turns ON and OFF generation of checking 
code for subrange violations. The default value is ON. 

bf. Tables 

This compiler option causes an idendifier map to be produced at 
the end of each procedure, function or outer block. The map includes 
the class, type, and address or constant value for each identifier. 
The default setting is OFF. See the Pascal/3000 reference manual. 

bg. Tabulate_Change_Info NOT IMPLEMENTED 



This compiler option cause change information to appear in the right margin of the listing. The 
Begin_Change and End_Change options are not listed while Tabulate_Change_lnfo is ON. The 
default setting is ON. See Begin_Change option. 

bh. Tag_Checking (nill be implemented) 

This compiler option causes checking code for references to 
fields in the variant part of records to be checked against tag 
fields. The default setting is OFF. 
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bi. Target_Machine 

This compiler option specifies which target machine to generate 
code for. 

bj. Title 

This compiler option specifies the string to be printed next to 
the page number on subsequent pages of the listing. See the 
Pascal/3000 reference manual. 

bk. Type_Coereion 

This compiler option specifies the level of type coercion to al- 
low. The default setting is none. 

bl. Undefined_Parm_Checking NOT IMPLEMENTED 

This compiler option turns ON and OFF the generation of checking 
code for references to optional parameters. Default is OFF. 

bin. Undefined Var Checking NOT IMPLEMENTED 



This compiler option turns ON and OFF the generation of checking code for references to local 
variables not yet assigned to. Default is OFF. 



bn. Us Unit 

This compiler option causes the USL file to be initialized to 
empty. See the Pascal/3000 reference manual. 

bo. Width 

This compiler option specifies the number of columns which the 
compiler will process from each input record. See the Pascal/3000 
reference manual. 

bp. XCall_Machine 

See extremely flexible procedure CALL mechanism section. 

bq. Xref 

This compiler option causes a cross reference listing to be 
produced for each procedure, function or outer block. The default 
setting is OFF. See the Pascal/3000 reference manual. 
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L MODCAL Data Types 



Appendix B 



Simple Types 
Ordinal Types 

Integer Based Types - integer 
Character Based Types - char 
Enumerated Based Types 
Predefined - boolean 
User Defined 
Real Types 

Single Binary Fit. Pt. - real 
Double Binary Fit. Pt. - longreal 
Reference Types 

Routine Reference Types 

Procedural Types - PROCEDURE 
Functional Types - FUNCTION : 
Data Reference Types 
Pointer Types - A 
Object Types - % 
Offset Types - OFFSET TO 
Structured Types 

Simple Structured Types 

Record Types - RECORD CASE OF END 
Array Types - ARRAY [] OF 
Set Types - SET OF 
Descripted Structured Types 
Nonimbedded Descriptor Types 

Schema Arrays -().'" ARRAY [] OF 
Discriminated Schemas - () 
Imbedded Descriptor Types 
File Types - FILE OF 
String Types - STRING [] 
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MODCAL Data Representation 

+ + + + + + 
Reference Part ++++++ 

Location Information + + + + + + 

Nonimbedded Descriptor Information + + + + + 

Data Value Part + + + + 

Imbedded Descriptor Information + + + + 

Active Component Position Information • — + + + + 

Valid Component Count Information ■ -+ + + 

Value Bit Vector • + + 

Referenced Item Reference Part + 
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a. Location Information 

The location information portion of the reference part of a data 
item describes how to locate the data value part of the data item. In 
its most generalized form this is an object offset pair or a static- 
link STT-entry pair. 



b. Nonimbedded Descriptor Information 

The nonimbedded discriptor information portion of the reference 
part of a data item describes what the discriminant_values associated 
with that data item are. This can be viewed as dope vector 
information. 



c. Active Component Position Information 

The active component position information portion of the data 
value part of a data item describes which component of a sequence of 
data items is currently contained in the value bit vector portion of 
the data value part. This portion may contain additional 
information. 



d. Valid Component Count Information 

The valid component count information portion of the data value 
part of a data item discribes the number of valid components current- 
ly contained in the value bit vector portion of the data value part. 



e. Value Bit Vector 

The value bit vector portion of the data value part of a data 
item is the actual bit vector representing the value of the data 
item. The value bit vector portion of structured data items contains 
the value bit vector protions of all of the component data items plus 
any "padding" bits. 



f . Referenced Item Reference Part 

The referenced item reference part portion of the data value 
part of a data item contains the refernce part of the referenced 
(pointed to) data item. This portion contains all the information 
needed to locate and access the referenced (pointed to) data item. 
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Appendix C: Type Compatibility 



1. Pascal Compatible Type Compatibilities 

Implicit Type Conversion for assignment 

Identical Types (Tl <=> T2) 
if either 

(1) Tl. identifier = T2. identifier 

(2) TYPE Tl. identifier = T2.idenitifier; 
appears in a declaration part 

Compatible Types (Tl <= T2) 
if any 

(1) Tl and T2 are Identical Types 

(2) Tl and T2 are subranges of T3, or 
Tl is a subrange of T2, or 

T2 is a subrange of Tl 

(3) TYPE Tl = SET OF T3; T2 = SET OF TU;, 
and T3 and TU are Compatible Types, 
and TL. packing = T2. packing 

(U) Tl and T2 are PAC types with the same length or if a 
value of either Tl or T2 is a literal whose length 
<= the length of the other type which is a literal 
or PAC, the literal is extended on the right with 
blanks to reach a compatible type. 

(5) Tl is a string type and T2 is a string type 
or literal. 

(6) Tl and T2 are both Floating Point Types 

Assignment Compatible Types (Tl <= T2) 

A value of type T2 is assignment compatible with a 
type Tl if any of the statements that follow are true 
and the restrictions following them are observed. 

(1) Tl and T2 are compatible types which are neither 
file types nor structured types which (recursively) 
contain file types. 

(2) Tl is a Real Type, 

and T2 is an Integer Type 

(3) Tl is a procedure type and T2 is a procedure 
with a parameter list congruent (as defined 
in HP Pascal) to the parameter list of Tl 

(U) Tl is a function type and T2 is a function 
with a parameter list congruent to the 
parameter list of Tl and result type identical 
to the result type of Tl 

The following rules must hold: 

(1) If Tl and T2 are Ordinal Types, 

then the value of type T2 must be in 
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interval specified by Tl 

(2) If Tl and T2 are Set Types, then 

all members of the value of type T2 must be in 
the interval of the base type of Tl 

(3) If Tl is a string type, and T2 is any 

string type or string literal, the length of the 
value of T2 must be <= the maximun length of Tl. 
The length of the variable of type Tl is set to 
the length of the value of type T2. 
(U) If Tl is a procedure or function type, then value 
of T2 must have the same or wider scope than the 
variable or parameter of type Tl being assigned 
to. 



2. Pascal Incompatible Type Compatibilities 

Explicit Type Coercion required for assignment 

Structurally Compatible Types (Tl <=> T2) 

Same number, order, and packing of Structurally 
Compatible Typed components (1 for 1 mapping) 

Two types Tl and T2 are structurally compatible if 
any of the following are true: 

(1) Tl and T2 are identical types 

(2) Tl and T2 are ordinal types and the 

ORD (minimum value of T1)=0RD (minimum value of 
T2) and the ORD (maximum value of T1)=0RD( 
maximum value of T2) 
AND 

Tl & T2 base types are user enumerated types, 

OR Tl & T2 base types are integer, 

OR Tl & T2 base types are boolean, 

OR Tl & T2 base types are char. 

(3) Tl and T2 are types of a procedure. Two 
procedures have structurally compatible types 
if they have the same number of parameters 
and each corresponding parameter has the 
same form (Var or value) and the type of 
each corresponding parameter is structurally 
compatible 

(U) Tl and T2 are types of a function. Two 

functions have structurally compatible types 
if they have the same number of parameters 
and each corresponding parameter has the 
same form (Var or value) and the type of 
each corresponding parameter is structurally 
compatible and the results types of both 
functions are structurally compatible 

(5) Tl and T2 are data reference types of identical 

form (i.e. both are either pointer, object, offset) 
which reference data with structurally compatible types. 
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(6) Tl and T2 are record types with the same 
packing and each field in Tl is structurally 
compatible with the corresponding field in 
T2 and the number of fields in Tl= the 
number of fields in T2 

(7) Tl and T2 are array types with identical packing 
and structurally compatible components and index 
types 

(8) Tl and T2 are set types with identical packing and 
structurally compatible base types 

(9) Tl and T2 are file types with structurally compatible 
component types 

(10)T1 and T2 are schema types with structurally compatible 
index types and structurally compatible component types 
and identical packing 

(11)T1 and T2 are string types with identical maximum 
lengths 



Representation Size Compatible Types (Tl <= T2) 
BitSizeOf '(Tl) = BitSize0f(T2) 

Storage Size Compatible Types (Tl <= T2) 
SUSizeOfiTl) >= SUSizeOf(T2) 

NonCompatible Types (Tl <=> T2) 

(1) SizeOfCn) < Size0f{12) 

(2) Size0f(11) = Size0f{12) 

(3) SizeOf(TL) > SizeO/(T2) 
- ANYTHING GOES - 

Pascal/Modcal Special Case Compatibilities 

(1) All Reference Types are Type Compatible with NIL 

(2) All Set Types are Type Compatible with [] 
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Appendix D: MODCAL Reserved Words 



1. ANSI Standard Pascal Reserved Words 



AND 


FUNCTION 


PROGRAM 


ARRAY 


GOTO 


RECORD 


BEGIN 


IF 


REPEAT 


CASE 


IN 


SET 


CONST 


LABEL 


THEN 


DIV 


MOD 


TO 


DO 


NIL 


TYPE 


DOWNTO 


NOT 


UNTIL 


ELSE 


OF 


VAR 


END 


OR 


WHILE 


FILE 


PACKED 


WITH 


FOR 


PROCEDURE 





2. HP Standard Pascal Additions 

OTHERWISE 

3. HP Standard MODCAL Additions 



DEFINITION 


IMPORT 


READONLY 


EXPORT 


MODULE 


RECOVER 


HIDDEN 


QUALIFIED 


TRY 


IMPLEMENT 







4. BCG Experimental MODCAL Additions 

OFFSET 



ANYVAR 

OPTION 



CRUNCHED 
WITHOBJECT 
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